WO2021043063A1 - 凭证验证方法、装置、设备与可读存储介质 - Google Patents

凭证验证方法、装置、设备与可读存储介质 Download PDF

Info

Publication number
WO2021043063A1
WO2021043063A1 PCT/CN2020/111798 CN2020111798W WO2021043063A1 WO 2021043063 A1 WO2021043063 A1 WO 2021043063A1 CN 2020111798 W CN2020111798 W CN 2020111798W WO 2021043063 A1 WO2021043063 A1 WO 2021043063A1
Authority
WO
WIPO (PCT)
Prior art keywords
verification
certificate
equity
restriction information
server
Prior art date
Application number
PCT/CN2020/111798
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 WO2021043063A1 publication Critical patent/WO2021043063A1/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/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/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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3252—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using DSA or related signature schemes, e.g. elliptic based signatures, ElGamal or Schnorr schemes

Definitions

  • This application relates to the technical field of Blockchain, and in particular relates to credential verification methods, devices, equipment and readable storage media.
  • the main purpose of this application is to propose a voucher verification method, device, equipment and computer-readable storage medium, aiming to realize the autonomous verification of equity voucher.
  • this application provides a credential verification method, which includes the following steps:
  • the service content includes a service promise, a service identification, and a first digital signature
  • the step of verifying the service content based on the verification key, the service item, and the signature public key includes:
  • the redemption record includes encrypted transaction restriction information and a second digital signature
  • the step of verifying the redemption record based on the redemption postscript includes:
  • the signature public key is used to verify whether the second digital signature is a valid signature to the encrypted transaction restriction information, and if it is, it is determined that the redemption record verification is passed.
  • the voucher verification method further includes:
  • the server when the server receives the encrypted transaction restriction information, it verifies whether the redemption request is valid based on the encrypted transaction restriction information, and when it is determined that the redemption request is valid, the server will The encrypted transaction restriction information is uploaded to the contract data table of the blockchain.
  • the step of determining the encrypted transaction restriction information of the equity certificate, and sending the encrypted transaction restriction information to the server includes:
  • the server when the server receives the encrypted transaction restriction information, it verifies whether the redemption request is valid based on the encrypted transaction restriction information, and when it is determined that the redemption request is valid, the service
  • the step of uploading the encrypted transaction restriction information to the contract data table of the blockchain includes:
  • the server When receiving the encrypted transaction restriction information, the server uses the data private key corresponding to the data public key to decrypt the encrypted transaction restriction information to obtain the transaction restriction information;
  • the server verifies whether the redemption postscript of the transaction restriction information is reasonable
  • the server determines that the redemption postscript is reasonable, it uses the signature private key of the server to sign the encrypted transaction restriction information, generates the second digital signature, and combines the second digital signature with the The encrypted transaction restriction information is uploaded to the contract data table of the blockchain.
  • the step of determining the encrypted transaction restriction information of the equity certificate, and sending the encrypted transaction restriction information to the server includes:
  • the encrypted transaction restriction information of the equity certificate and the zero-knowledge proof of the equity certificate are determined, and the encrypted transaction restriction information and the zero-knowledge proof are sent to The server;
  • the step of the server uploading the encrypted transaction restriction information to the contract data table of the blockchain includes:
  • the server uploads the encrypted transaction restriction information and the zero-knowledge certificate to the blockchain, and the blockchain verifies the redemption record of the equity certificate based on the zero-knowledge certificate;
  • the block chain marks the redemption record of the equity certificate as redeemed, and saves the encrypted transaction restriction information in the contract data table.
  • the credential verification method further includes:
  • the step of the server generating the globally unique encrypted credential based on the verification key and the service item corresponding to the equity credential includes:
  • the server When the server receives the verification key, it generates a corresponding service commitment based on the verification key and the service item corresponding to the equity certificate;
  • the server generates the globally unique encryption certificate based on the service promise and the service identifier of the blockchain.
  • this application also provides a credential verification device, the credential verification device including:
  • the detection module is configured to, if a verification request initiated based on the equity certificate is detected, obtain the service content of the equity certificate and the redemption record of the equity certificate from the contract data table of the blockchain corresponding to the verification request;
  • the verification module is used to obtain the verification key of the equity certificate, the service item of the equity certificate, and the signature public key of the server corresponding to the equity certificate, and based on the verification key, the service item, and the Sign the public key to verify the service content;
  • the verification module is further configured to obtain a redemption postscript of the equity voucher if the service content is verified, and verify the redemption record based on the redemption postscript;
  • the determining module is configured to determine that the equity certificate is valid if the verification of the redemption record is passed.
  • the service content includes a service promise, a service identification, and a first digital signature
  • the verification module is further configured to:
  • the redemption record includes encrypted transaction restriction information and a second digital signature
  • the verification module is further configured to:
  • the signature public key is used to verify whether the second digital signature is a valid signature to the encrypted transaction restriction information, and if it is, it is determined that the redemption record verification is passed.
  • the detection module is further used for:
  • the server when the server receives the encrypted transaction restriction information, it verifies whether the redemption request is valid based on the encrypted transaction restriction information, and when it is determined that the redemption request is valid, the server will The encrypted transaction restriction information is uploaded to the contract data table of the blockchain.
  • the detection module is further used for:
  • the server when the server receives the encrypted transaction restriction information, it verifies whether the redemption request is valid based on the encrypted transaction restriction information, and when it is determined that the redemption request is valid, the service
  • the step of uploading the encrypted transaction restriction information to the contract data table of the blockchain includes:
  • the server When receiving the encrypted transaction restriction information, the server uses the data private key corresponding to the data public key to decrypt the encrypted transaction restriction information to obtain the transaction restriction information;
  • the server verifies whether the redemption postscript of the transaction restriction information is reasonable
  • the server determines that the redemption postscript is reasonable, it uses the signature private key of the server to sign the encrypted transaction restriction information, generates the second digital signature, and combines the second digital signature with the The encrypted transaction restriction information is uploaded to the contract data table of the blockchain.
  • the detection module is further used for:
  • the encrypted transaction restriction information of the equity certificate and the zero-knowledge proof of the equity certificate are determined, and the encrypted transaction restriction information and the zero-knowledge proof are sent to The server;
  • the step of the server uploading the encrypted transaction restriction information to the contract data table of the blockchain includes:
  • the server uploads the encrypted transaction restriction information and the zero-knowledge certificate to the blockchain, and the blockchain verifies the redemption record of the equity certificate based on the zero-knowledge certificate;
  • the block chain marks the redemption record of the equity certificate as redeemed, and saves the encrypted transaction restriction information in the contract data table.
  • the detection module is further used for:
  • the detection module is further used for:
  • the server When the server receives the verification key, it generates a corresponding service commitment based on the verification key and the service item corresponding to the equity certificate;
  • the server generates the globally unique encryption certificate based on the service promise and the service identifier of the blockchain.
  • this application also provides a credential verification device, the credential verification device comprising: a memory, a processor, and a credential verification program stored on the memory and running on the processor, so When the credential verification program is executed by the processor, the steps of the credential verification method described above are implemented.
  • the present application also provides a computer-readable storage medium having a credential verification program stored on the computer-readable storage medium, and when the credential verification program is executed by a processor, the credential verification as described above is realized. Method steps.
  • the service content of the equity voucher and the value of the equity voucher are obtained from the contract data table of the blockchain corresponding to the verification request. Redemption record; obtain the verification key of the verification request, the service item of the equity certificate, and the signature public key of the server corresponding to the equity certificate, and based on the verification key, the service item, and the signature public key Key to verify the service content; if the service content is verified, obtain the redemption postscript of the equity voucher, and based on the redemption postscript, verify the redemption record; if the redemption record passes the verification, then Confirm that the equity certificate is valid.
  • the equity certificate verification of this application does not require server participation.
  • FIG. 1 is a schematic diagram of a device structure of a hardware operating environment involved in a solution of an embodiment of the present application
  • FIG. 2 is a schematic flowchart of the first embodiment of the application credential verification method.
  • FIG. 1 is a schematic diagram of the device structure of the hardware operating environment involved in the solution of the embodiment of the present application.
  • the device in the embodiment of the present application may be a PC or a server device.
  • the device may include: a processor 1001, such as a CPU, a network interface 1004, a user interface 1003, a memory 1005, and a communication bus 1002.
  • the communication bus 1002 is used to implement connection and communication between these components.
  • the user interface 1003 may include a display screen (Display) and an input unit such as a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface.
  • the network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface).
  • the memory 1005 may be a high-speed RAM memory, or a non-volatile memory (non-volatile memory), such as a magnetic disk memory.
  • the memory 1005 may also be a storage device independent of the aforementioned processor 1001.
  • FIG. 1 does not constitute a limitation on the device, and may include more or fewer components than those shown in the figure, or a combination of certain components, or different component arrangements.
  • the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a credential verification program.
  • the operating system is a program that manages and controls credential verification equipment and software resources, and supports the operation of network communication modules, user interface modules, credential verification programs, and other programs or software; the network communication module is used to manage and control the network interface 1002; the user interface module Used to manage and control the user interface 1003.
  • the credential verification device invokes the credential verification program stored in the memory 1005 through the processor 1001, and executes the operations in each embodiment of the credential verification method described below.
  • Fig. 2 is a schematic flowchart of a first embodiment of a credential verification method for this application, and the method includes:
  • Step S10 if a verification request initiated based on the equity certificate is detected, obtain the service content of the equity certificate and the redemption record of the equity certificate from the contract data table of the blockchain corresponding to the verification request;
  • Step S20 Obtain the verification key of the verification request, the service item of the equity certificate, and the signature public key of the server corresponding to the equity certificate, and based on the verification key, the service item, and the signature public key Key to verify the service content;
  • Step S30 if the service content verification is passed, obtain the redemption postscript of the equity voucher, and verify the redemption record based on the redemption postscript;
  • Step S40 if the verification of the redemption record is passed, it is determined that the equity certificate is valid.
  • the credential verification method of this embodiment is applied to credential verification devices of financial institutions such as financial institutions or banks.
  • the credential verification device can be a terminal, a robot, or a PC device.
  • the credential verification device is described as a credential device.
  • the credential device can be the device used by the internal staff of the financial institution, or the software and hardware system issued by the financial institution, and the credential device formed by the user's self-installation on their own terminal equipment.
  • the voucher device can be connected to the server through network communication, and there is a blockchain between the voucher device and the server.
  • the server is the service provider of the equity voucher and is responsible for selling relevant equity voucher, and the user holding the voucher device is The buyer can purchase or redeem equity certificates from the server through network communication, and can independently verify the equity certificates, while the blockchain records the transaction behavior between the certificate device and the server.
  • the voucher device of this embodiment when detecting a verification request initiated based on the equity voucher, downloads the service content and redemption record required for verification from the contract data table of the blockchain, and verifies the service content and redemption record in turn. If the verification is passed, it is determined that the equity certificate is valid, that is, the equity certificate is valid evidence and can be held accountable through the equity certificate. During the verification process, due to the non-tamperable feature of the blockchain, the server does not need to participate, and the certificate device can be autonomous carry out.
  • Step S10 if a verification request initiated based on the equity certificate is detected, obtain the service content of the equity certificate and the redemption record of the equity certificate from the contract data table of the blockchain corresponding to the verification request.
  • the verification request can be initiated through the voucher device.
  • the voucher device may be a mobile terminal such as the buyer's mobile phone.
  • the voucher device detects a verification request initiated based on the equity voucher, it downloads the service content and redemption records corresponding to the equity voucher from the contract data table of the blockchain corresponding to the verification request, that is, the contract data table of the blockchain records
  • the transaction behavior between the voucher device and the server specifically includes service content and redemption records.
  • the service content is the service item corresponding to the equity voucher, that is, what is the specific service corresponding to the equity voucher, and the redemption record is whether the equity voucher is redeemed . Due to the non-tamperable nature of the blockchain, the credential device downloading relevant service content and redemption records from the blockchain is more impartial and can also ensure the authenticity of the relevant data.
  • Step S20 Obtain the verification key of the equity certificate, the service item of the equity certificate, and the signature public key of the server corresponding to the equity certificate, and based on the verification key, the service item, and the signature public key Key to verify the service content.
  • the voucher device verifies the service content and redemption in turn.
  • the verification key is preset by the buyer when purchasing the current equity voucher.
  • Set a key that is, only the buyer knows the verification key in principle. Therefore, in specific implementation, the voucher device can obtain the verification key of the equity certificate by receiving the verification key input by the buyer, and then obtain the service of the equity certificate Project, and the signature public key of the server corresponding to the equity certificate.
  • the signature public key is known on the blockchain. Therefore, the certificate device connected to the blockchain can obtain it. Then, the certificate device is based on the verification key, service item and The signed public key verifies the content of the service.
  • the service content includes a service promise, a service identifier, and a first digital signature
  • step S20 includes:
  • Step a Based on the verification key and the service item, calculate a corresponding pledge to be verified, and determine whether the pledge to be verified is consistent with the service promise;
  • the service content downloaded by the credential device from the contract data table of the blockchain includes the service promise, the service identification and the first digital signature.
  • the verification key and the service are used. Project, calculate the commitment to be verified, and determine whether the commitment to be verified is consistent with the service commitment downloaded from the contract data table of the blockchain.
  • the credential device obtains the first public parameter G and the second public parameter H, where G and H are previously disclosed parameters.
  • the regulatory arbitrator will disclose through a trusted channel. Therefore, the credential The device can obtain it, and then, according to the verification key, service items, preset formula, G and H, calculate the commitment to be verified.
  • the function here, is to convert the service item into a value.
  • the hash function Hash may be used as the Encode function.
  • the service commitment is obtained by the above calculation method when the buyer purchases the equity voucher through the voucher device and stored in the contract data table of the blockchain. Therefore, it is only necessary to verify whether the currently calculated pledge to be verified is Consistent with the service promise in the contract data sheet of the blockchain.
  • Step b If yes, use the signature public key to verify whether the first digital signature is a valid signature to the globally unique encryption certificate, and if so, determine that the service content verification is passed, wherein the globally unique encryption certificate is determined by The service promise and the service identification are generated.
  • the server's signature public key is further used to verify whether the first digital signature is a valid signature of the globally unique encryption certificate, that is, verification Whether the server knows and acknowledges the current equity certificate, what needs to be explained is that the first digital signature is obtained by the server using the signature private key to sign the globally unique encryption certificate. Therefore, it needs to be verified with the signature public key of the server.
  • the globally unique encrypted certificate can be generated separately by the service promise, that is, before the verification, the service promise of the current equity certificate is calculated by the server (the specific calculation method is similar to the calculation of the promise to be verified above, and the verification key is determined by the buyer Send to the server through the credential device), and use the signature private key to sign the service commitment, thereby obtaining the first digital signature.
  • the value of r and Encode service item
  • this embodiment preferably introduces a globally unique identification number—the service identifier.
  • the server uses the service promise and the service identifier to form a globally unique encrypted certificate.
  • the service ID is a global single-increasing sequence number that only increases and does not decrease. Once the service ID in any history record is generated, the data in the same table will not be deleted.
  • the service identification can be obtained by using the atomicity of the transaction executed by the blockchain smart contract, which will not be detailed here, and the service identification obtained by the credential device during the verification process is from the contract data table of the blockchain Downloaded in.
  • step S30 if the service content verification is passed, the redemption postscript of the equity voucher is obtained, and the redemption record is verified based on the redemption postscript.
  • the voucher device determines that the service content of the equity voucher is verified, it further obtains the redemption postscript of the equity voucher, where the redemption postscript refers to the set by the buyer when purchasing the current equity voucher and is of the server
  • the information recognized by the service provider such as the current equity certificate can be used in the No. 301-501 shop designated by the service provider, the buyer can set "Use in the No. 301 shop" as the redemption postscript through the voucher device at the beginning of the purchase, and then, the voucher Based on the redemption postscript of the current equity certificate, the device verifies the redemption record of the equity certificate in the blockchain.
  • the redemption record includes encrypted transaction restriction information and a second digital signature
  • step S30 includes:
  • Step c verifying whether the encrypted transaction restriction information is correct based on the redemption postscript
  • the voucher device verifies whether the encrypted transaction restriction information is correct according to the redemption postscript of the current equity voucher.
  • the specific verification process is:
  • E_condition E_PK_data_s(maxBlockNumber, claimMessage)
  • maxBlockNumber is the preset block height
  • claimMessage is the redemption postscript
  • PK_data_s is the data public key of the server, which is to verify whether the plaintext of the encrypted transaction restriction information corresponds to the ciphertext.
  • Step d if it is correct, use the signature public key to verify whether the second digital signature is a valid signature to the encrypted transaction restriction information, and if it is, it is determined that the redemption record has been verified.
  • E_condition E_PK_data_s(maxBlockNumber, claimMessage) holds, that is, the encrypted transaction restriction information is verified correctly
  • the signature public key of the server is used to verify whether the second digital signature is a valid signature to the encrypted transaction restriction information, that is, the service is confirmed Does the client know and acknowledge the encrypted transaction restriction information?
  • the second digital signature is obtained by the server using its signature private key to sign the encrypted transaction restriction information. Therefore, the certificate device uses the signature public key to verify whether the second digital signature is A valid signature of restricted information for encrypted transactions.
  • the second digital signature is a valid signature for the encrypted transaction restriction information, it is determined that the verification of the redemption record is passed.
  • Step S40 if the verification of the redemption record is passed, it is determined that the equity certificate is valid.
  • the voucher device determines that both the service content and the redemption record of the current equity voucher are verified, it is determined that the current equity voucher is valid and can be displayed to the regulatory arbitrator as evidence.
  • the current equity voucher is determined to be invalid and cannot be used as evidence for accountability.
  • the service content of the equity certificate and the redemption record of the equity certificate are obtained from the contract data table of the blockchain corresponding to the verification request;
  • the equity certificate verification of this application does not require server participation.
  • the credential verification method further includes:
  • Step S50 If a redemption request initiated based on the equity certificate is detected, the encrypted transaction restriction information of the equity certificate is determined, and the encrypted transaction restriction information is sent to the server;
  • Step S60 detecting whether the encrypted transaction restriction information exists in the contract data table of the blockchain, and if it exists, it is determined that the equity certificate is fully redeemed;
  • the server when the server receives the encrypted transaction restriction information, it verifies whether the redemption request is valid based on the encrypted transaction restriction information, and when it is determined that the redemption request is valid, the server will The encrypted transaction restriction information is uploaded to the contract data table of the blockchain.
  • the encrypted transaction restriction information needs to be sent to the server, and the server uploads the encrypted transaction restriction information to the contract data table of the blockchain.
  • the encrypted transaction restriction information is detected in the contract data table, it is determined that the redemption of the equity certificate is completed.
  • Step S50 If a redemption request initiated based on the equity certificate is detected, the encrypted transaction restriction information of the equity certificate is determined, and the encrypted transaction restriction information is sent to the server.
  • the voucher device detects a redemption request based on the equity voucher, it determines the encrypted transaction restriction information of the equity voucher, and sends the encrypted transaction restriction information to the server, that is, the buyer redeems the rights through the voucher device
  • the server that is, the buyer redeems the rights through the voucher device
  • it is necessary to determine the encrypted transaction restriction information of the equity voucher, and then send the encrypted transaction restriction information to the server for confirmation by the server.
  • the equity voucher is issued by the server and the buyer holds the equity voucher , And when cashing is required, cashing is required to the server, and the proof required for cashing is the encrypted transaction restriction information.
  • step S50 includes:
  • Step e if a redemption request initiated based on the equity certificate is detected, obtain the redemption postscript of the equity certificate, and generate corresponding transaction restriction information based on the redemption postscript and the preset block height;
  • the voucher device detects a redemption request initiated based on the equity certificate, it obtains the redemption postscript of the equity certificate, and generates corresponding transaction restriction information based on the redemption postscript and the preset block height, where the preset block
  • the high is the proof device according to the block height corresponding to the current blockchain node, plus a reasonable upper limit.
  • the block height of the current blockchain node +10 is the preset block height.
  • the reasonable upper limit can be adjusted according to the actual situation. Understandably, the block height of the blockchain node continues to increase with the occurrence of transactions. In order to ensure the security of the transaction, a reasonable upper limit needs to be set to ensure that the block height of the current blockchain node is verified when the subsequent blockchain verifies the cashing record.
  • Step f Obtain the data public key of the server, and use the data public key to encrypt the transaction restriction information to obtain the encrypted transaction restriction information, and send the encrypted transaction restriction information to the service end.
  • the credential device obtains the data public key of the server, which is known in the blockchain, and uses the data public key to encrypt the transaction restriction information, thereby obtaining the encrypted transaction restriction information, and sends the encrypted transaction restriction information to the service end.
  • Step S60 detecting whether the encrypted transaction restriction information exists in the contract data table of the blockchain, and if it exists, it is determined that the equity certificate is fully redeemed;
  • the server When receiving the encrypted transaction restriction information, the server verifies whether the redemption request is valid based on the encrypted transaction restriction information, and when determining that the redemption request is valid, the server sends the encrypted transaction
  • the restriction information is uploaded to the contract data table of the blockchain.
  • the voucher device after the voucher device sends the encrypted transaction restriction information to the server, it only needs to determine in the contract data table of the blockchain whether there is encrypted transaction restriction information that is consistent with that sent to the server. If it exists, then Confirm that the cashing of the current equity certificate is completed.
  • the transaction process is: the voucher device sends the encrypted transaction restriction information to the server, and when the server receives the encrypted transaction restriction information, it verifies whether the redemption request initiated by the voucher device is valid according to the encrypted transaction restriction information. Whether the current equity certificate is valid, whether the current equity certificate has not been redeemed, etc., and when the redemption request is determined to be valid, the server uploads the encrypted transaction restriction information to the contract data table of the blockchain.
  • the process of uploading the encrypted transaction restriction information to the contract data table of the blockchain on the server side includes:
  • Step g When receiving the encrypted transaction restriction information, the server uses the data private key corresponding to the data public key to decrypt the encrypted transaction restriction information to obtain the transaction restriction information;
  • the server since the encrypted transaction restriction information is encrypted with the server's data public key, when the server receives the encrypted transaction restriction information, it uses the corresponding data private key to decrypt the encrypted transaction restriction information, thereby obtaining Transaction restriction information. Since the transaction restriction information consists of the redemption postscript and the preset block height, the preset block height and the redemption postscript corresponding to the current equity certificate are also obtained.
  • Step h the server verifies whether the redemption postscript of the transaction restriction information is reasonable
  • the redemption postscript Compare the redemption postscript with the default redemption postscript corresponding to the server, and determine whether the redemption postscript is in the default redemption postscript. For example, the default redemption postscript of the server for the equity certificate is "in No.301-501" Store use”, then when the redemption postscript is between the 301-501 store, such as "use in the 302 store", then the redemption postscript is considered reasonable.
  • Step i If the server determines that the redemption postscript is reasonable, then use the signature private key of the server to sign the encrypted transaction restriction information, generate the second digital signature, and add the second digital The signature and the encrypted transaction restriction information are uploaded to the contract data table of the blockchain.
  • the server After confirming that the postscript is reasonable, the server needs to leave evidence to prove that it knows and acknowledges the encrypted transaction restriction information. Therefore, the server uses the signature private key to sign the encrypted transaction restriction information to generate a second digital signature. Finally, Upload the encrypted transaction restriction information and the second digital signature to the contract data table of the blockchain.
  • This embodiment is to accurately verify the equity certificate in the follow-up.
  • the encrypted transaction restriction information needs to be sent to the server as evidence for the server to sign, and then the server uploads to the contract data table of the blockchain
  • the information downloaded by the subsequent voucher device from the contract data table of the blockchain is credible, and the server cannot deny it, thereby improving the feasibility of autonomous verification of equity voucher.
  • step S50 includes:
  • Step j If a redemption request initiated based on the equity certificate is detected, the encrypted transaction restriction information of the equity certificate and the zero-knowledge proof of the equity certificate are determined, and the encrypted transaction restriction information and the zero-knowledge The certificate is sent to the server;
  • the step of the server uploading the encrypted transaction restriction information to the contract data table of the blockchain includes:
  • Step k the server uploads the encrypted transaction restriction information and the zero-knowledge proof to the blockchain, and the blockchain verifies the redemption record of the equity certificate based on the zero-knowledge proof;
  • the block chain marks the redemption record of the equity certificate as redeemed, and saves the encrypted transaction restriction information in the contract data table.
  • the voucher device of this embodiment sends the encrypted transaction restriction information of the equity certificate to the server, it also sends the zero-knowledge proof together so that the server can upload the encrypted transaction restriction information and the zero-knowledge proof to the blockchain.
  • the block chain verifies the redemption record of the current equity certificate based on the zero-knowledge proof. If the verification is passed, the encrypted transaction restriction information is saved in the contract data table. At this time, the redemption of the equity certificate is completed.
  • Step j If a redemption request initiated based on the equity certificate is detected, the encrypted transaction restriction information of the equity certificate and the zero-knowledge proof of the equity certificate are determined, and the encrypted transaction restriction information and the zero-knowledge The proof is sent to the server.
  • the voucher device can provide the server with proof that he knows the verification key to redeem the corresponding service item, but because the blockchain needs to broadcast the certificate before the transaction takes effect
  • the plaintext of the data, that is, the verification key needs to be broadcast. However, if the verification key is broadcasted, it will bring losses to the buyer. Therefore, the plaintext of the verification key cannot be directly broadcast to complete the redemption.
  • zero-knowledge proof zk_proof means that the prover can convince the verifier that a certain assertion is correct without providing any useful information to the verifier.
  • Zero-knowledge proof is essentially an agreement involving two or more parties, that is, a series of steps that two or more parties need to take to complete a task. The prover proves to the verifier and makes it believe that he knows or possesses a certain message, but the certification process cannot leak any information about the certified message to the verifier.
  • the voucher device detects a redemption request initiated based on the equity certificate, it determines the encrypted transaction restriction information and zero-knowledge proof of the equity certificate.
  • the determination process of zero-knowledge proof includes:
  • E_condition), where T1 a*G+b*H, G and H are public parameters, serviceCommitment is service commitment, E_condition is encrypted transaction restriction information , And the symbol
  • "c" "abc".
  • the credential device sends the encrypted transaction restriction information and the zero-knowledge proof to the server.
  • the voucher device can select corresponding parameters according to the actual situation to generate the zero-knowledge proof.
  • step of the server uploading the encrypted transaction restriction information to the contract data table of the blockchain includes:
  • Step k the server uploads the encrypted transaction restriction information and the zero-knowledge proof to the blockchain, and the blockchain verifies the redemption record of the equity certificate based on the zero-knowledge proof;
  • the blockchain marks the redemption record of the equity certificate as redeemed, and saves the encrypted transaction restriction information in the contract data table.
  • the server also needs to verify the validity of the redemption request.
  • the specific steps are similar to the previous embodiment, and will not be repeated here.
  • the server uploads the encrypted transaction restriction information and the zero-knowledge proof to the blockchain, and the blockchain verifies the redemption record of the equity certificate based on the zero-knowledge proof.
  • the specific verification process includes:
  • the block chain marks the redemption record of the equity certificate as redeemed, and the encrypted transaction restriction information is stored in the contract data table. Specifically, after the verification is passed, the block chain passes the smart contract Generate a transaction and perform the following operations:
  • the zero-knowledge proof is used to prove the validity of the redemption request during the redemption process of the equity certificate, so that the redemption process is safe and secret, and it will not be easily verified in the subsequent verification process. Cracking makes the subsequent verification process more secure and credible, and improves the feasibility of self-verification of equity certificates.
  • the credential verification method further includes:
  • Step S70 if a purchase request initiated based on the equity certificate is detected, a preset verification key is sent to the server;
  • Step S80 Receive the globally unique encryption certificate corresponding to the equity certificate, the signature public key of the server and the first digital signature of the globally unique encryption certificate sent by the server, and verify whether the blockchain is There are the globally unique encryption certificate, the signature public key, and the first digital signature, wherein the server generates the globally unique encryption certificate based on the verification key and the service item corresponding to the equity certificate, And use the signature public key to sign the globally unique encryption certificate to obtain the first digital signature;
  • the block chain will record the transaction. Therefore, it is only necessary to check whether there is a corresponding record in the block chain to confirm the completion of the purchase.
  • step S70 if a purchase request initiated based on the equity certificate is detected, the preset verification key is sent to the server.
  • the voucher device detects a purchase request initiated by the buyer based on the equity voucher, it sends a preset verification key to the server, where the preset key is a random number selected by the buyer, which is understandable.
  • This transaction inevitably involves money. Since money does not contribute to subsequent verification, it will not be mentioned here.
  • Step S80 receiving the globally unique encryption certificate corresponding to the equity certificate sent by the server based on the purchase request, the signature public key of the server and the first digital signature of the globally unique encryption certificate, and verifying the Whether the globally unique encryption certificate, the signature public key, and the first digital signature exist in the blockchain, wherein the server generates the said service item based on the verification key and the service item corresponding to the equity certificate A globally unique encryption certificate, and use the signature public key to sign the globally unique encryption certificate to obtain the first digital signature;
  • the certificate device receives the globally unique encrypted certificate corresponding to the current equity certificate sent by the server based on the purchase request, the signature public key of the server and the first digital signature of the globally unique encrypted certificate, and verifies whether it exists in the blockchain If the same globally unique encryption certificate, the signature public key of the server and the first digital signature exist, it is determined that the purchase of the equity certificate is completed.
  • the server After the certificate device sends the verification key to the server, the server generates a globally unique encryption certificate according to the service items corresponding to the verification key and the equity certificate, and then uses the signature public key of the server to sign the globally unique encryption certificate, thereby obtaining the first A digital signature, and then return the globally unique encryption certificate and the first digital signature to the certificate device.
  • the step of the server generating the globally unique encrypted certificate based on the verification key and the service item corresponding to the equity certificate includes:
  • Step 1 When receiving the verification key, the server generates a corresponding service commitment based on the verification key and the service item corresponding to the equity certificate;
  • Step m The server generates the globally unique encryption certificate based on the service promise and the service identifier of the blockchain.
  • rG can also be calculated by the credential device and sent to the server.
  • the server also needs to call the smart contract of the blockchain Interface to obtain a globally unique identification number—service identification.
  • service identification In order to make the next service identification different from the current service identification, update the next service identification on the blockchain, specifically to make the next service identification +1, that is, the service identification serviceId It is a global single-increasing sequence number that only increases without decreasing.
  • the server calls the blockchain smart contract interface and saves (unique_c, PK_sig_s, Sig_c) in the unfulfilled contract data table, that is, the relevant record does not have a Used tag field attached, based on the non-tamperable feature of the blockchain, Every operation on the contract data table will leave an unchangeable record.
  • the specific process for the credential device to verify whether there is a globally unique encrypted credential, the signature public key of the server and the first digital signature in the contract data table of the blockchain is as follows:
  • the relationship between the client and the signature public key is to confirm that the server knows and acknowledges the equity certificate.
  • the server needs to send the signed public key and related certification materials to the regulatory arbitration party before issuing the equity certificate.
  • Register and apply for your own digital certificate supervise the arbitrator to verify the identity of the server, and use the root certificate of the CA to issue the corresponding digital certificate for the server.
  • the supervisory arbitrator saves the corresponding relationship between the digital certificate issued above and the real identity of the server.
  • the identity of the server is determined by verifying the signed public and private keys in the certificate.
  • the voucher device then goes to the contract data table of the blockchain to verify whether unique_c, PK_sig_s, and Sig_c exist. If so, the voucher device sends a confirmation message to the server to confirm that the correct equity certificate has been received, otherwise contact the server for correction. Specifically, an error message can be sent to the server, and the object of the error, that is, which proves that the parameter is incorrect, for the server to correct.
  • This embodiment uses the verification key of the voucher device to encrypt the transaction information of the equity voucher in the process of purchasing the equity voucher, thereby concealing the content of the equity voucher, thereby protecting the business secrets of the service provider and the personal privacy of the buyer.
  • the signature public key of the server is uploaded to the blockchain as transaction evidence, so that the server cannot deny that the relevant equity certificate has been sold, and the feasibility of subsequent independent verification of the equity certificate is improved.
  • This application also provides a credential verification device.
  • This application certificate verification device includes:
  • the detection module is configured to, if a verification request initiated based on the equity certificate is detected, obtain the service content of the equity certificate and the redemption record of the equity certificate from the contract data table of the blockchain corresponding to the verification request;
  • the verification module is used to obtain the verification key of the equity certificate, the service item of the equity certificate, and the signature public key of the server corresponding to the equity certificate, and based on the verification key, the service item, and the Sign the public key to verify the service content;
  • the verification module is further configured to obtain a redemption postscript of the equity voucher if the service content is verified, and verify the redemption record based on the redemption postscript;
  • the determining module is configured to determine that the equity certificate is valid if the verification of the redemption record is passed.
  • the service content includes a service promise, a service identification and a first digital signature
  • the verification module is further used for:
  • the redemption record includes encrypted transaction restriction information and a second digital signature
  • the verification module is further used for:
  • the signature public key is used to verify whether the second digital signature is a valid signature to the encrypted transaction restriction information, and if it is, it is determined that the redemption record verification is passed.
  • the detection module is also used for:
  • the server When receiving the encrypted transaction restriction information, the server verifies whether the redemption request is valid based on the encrypted transaction restriction information, and when determining that the redemption request is valid, the server sends the encrypted transaction
  • the restriction information is uploaded to the contract data table of the blockchain.
  • the detection module is also used for:
  • the server verifies whether the redemption request is valid based on the encrypted transaction restriction information, and when it is determined that the redemption request is valid, the server verifies that the redemption request is valid.
  • the steps of uploading the encrypted transaction restriction information to the contract data table of the blockchain include:
  • the server When receiving the encrypted transaction restriction information, the server uses the data private key corresponding to the data public key to decrypt the encrypted transaction restriction information to obtain the transaction restriction information;
  • the server verifies whether the redemption postscript of the transaction restriction information is reasonable
  • the server determines that the redemption postscript is reasonable, it uses the signature private key of the server to sign the encrypted transaction restriction information, generates the second digital signature, and combines the second digital signature with the The encrypted transaction restriction information is uploaded to the contract data table of the blockchain.
  • the detection module is also used for:
  • the encrypted transaction restriction information of the equity certificate and the zero-knowledge proof of the equity certificate are determined, and the encrypted transaction restriction information and the zero-knowledge proof are sent to The server;
  • the step of the server uploading the encrypted transaction restriction information to the contract data table of the blockchain includes:
  • the server uploads the encrypted transaction restriction information and the zero-knowledge certificate to the blockchain, and the blockchain verifies the redemption record of the equity certificate based on the zero-knowledge certificate;
  • the blockchain marks the redemption record of the equity certificate as redeemed, and saves the encrypted transaction restriction information in the contract data table.
  • the detection module is also used for:
  • the detection module is also used for:
  • the server When the server receives the verification key, it generates a corresponding service commitment based on the verification key and the service item corresponding to the equity certificate;
  • the server generates the globally unique encryption certificate based on the service promise and the service identifier of the blockchain.
  • the application also provides a computer-readable storage medium.
  • the computer-readable storage medium of the present application stores a credential verification program, and when the credential verification program is executed by a processor, the steps of the credential verification method described above are realized.
  • the method implemented when the credential verification program running on the processor is executed can refer to the various embodiments of the credential verification method of this application, which will not be repeated here.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种凭证验证方法、装置、设备和计算机可读存储介质，涉及区块链技术，该方法包括：若检测到基于权益凭证发起的验证请求，则从所述验证请求对应的区块链的合约数据表中，获取权益凭证的服务内容和权益凭证的兑现记录（S10）；获取所述验证请求的验证密钥、所述权益凭证的服务项目以及所述权益凭证对应的服务端的签名公钥，并基于所述验证密钥、所述服务项目和所述签名公钥，验证所述服务内容（S20）；若所述服务内容验证通过，则获取所述权益凭证的兑现附言，并基于所述兑现附言，验证所述兑现记录（S30）；若所述兑现记录验证通过，则确定权益凭证有效（S40）。

Description

凭证验证方法、装置、设备与可读存储介质
优先权信息
本申请要求于2019年9月6日申请的、申请号为201910851095.0、名称为“凭证验证方法、装置、设备与可读存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及区块链(Blockchain)技术领域，尤其涉及凭证验证方法、装置、设备与可读存储介质。
背景技术
近年来，随着金融科技(Fintech)，尤其是互联网金融的不断发展，互联网交易越来越多，交易产品也越来越多样，交易过程中，往往会遇到交易对象不是实体物品，而是一种权益凭证的时候，如各类预付卡，兑换券等，由于权益凭证的使用与费用支付的时间并不同步，买方往往是费用支付一段时间后，才去享受权益凭证对应的服务，并且，权益凭证一般由卖方提供，且相应的兑换数据保存在卖方私有的数据库中，这使得一旦出现纠纷，如卖家不承认出售过权益凭证，或者权益凭证已被兑换等，买方在无法享受权益凭证对应的服务的同时，也很难进行追责。
也即现有的权益凭证的验证需要卖方诚实参与，买方自身无法单独进行权益凭证的有效验证以进行追责。
发明内容
本申请的主要目的在于提出一种凭证验证方法、装置、设备与计算机可读存储介质，旨在实现权益凭证的自主验证。
为实现上述目的，本申请提供一种凭证验证方法，所述凭证验证方法包括如下步骤：
若检测到基于权益凭证发起的验证请求，则从所述验证请求对应的区块链的合约数据表中，获取所述权益凭证的服务内容和所述权益凭证的兑现记录；
获取所述权益凭证的验证密钥、所述权益凭证的服务项目以及所述权益凭证对应的服务端的签名公钥，并基于所述验证密钥、所述服务项目和所述签名公钥，验证所述服务内容；
若所述服务内容验证通过，则获取所述权益凭证的兑现附言，并基于所述兑现附言， 验证所述兑现记录；
若所述兑现记录验证通过，则确定所述权益凭证有效。
在一实施例中，所述服务内容包括服务承诺、服务标识和第一数字签名；
所述基于所述验证密钥、所述服务项目和所述签名公钥，验证所述服务内容的步骤包括：
基于所述验证密钥和所述服务项目，计算对应的待验证承诺，并确定所述待验证承诺是否与所述服务承诺一致；
若是，则使用所述签名公钥验证所述第一数字签名是否是对全局唯一加密凭证的有效签名，若是，则确定所述服务内容验证通过，其中，所述全局唯一加密凭证由所述服务承诺和所述服务标识生成。
在一实施例中，所述兑现记录包括加密交易限制信息和第二数字签名；
所述基于所述兑现附言，验证所述兑现记录的步骤包括：
基于所述兑现附言，验证所述加密交易限制信息是否正确；
若正确，则使用所述签名公钥验证所述第二数字签名是否是对所述加密交易限制信息的有效签名，若是，则确定所述兑现记录验证通过。
在一实施例中，所述若检测到基于权益凭证发起的验证请求，则从所述验证请求对应的区块链的合约数据表中，获取所述权益凭证的服务内容和所述权益凭证的兑现记录的步骤之前，所述凭证验证方法还包括：
若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息，并将所述加密交易限制信息发送至所述服务端；
检测所述区块链的合约数据表中是否存在所述加密交易限制信息，若存在，则确定所述权益凭证完成兑现；
其中，所述服务端在接收到所述加密交易限制信息时，基于所述加密交易限制信息，验证所述兑现请求是否有效，并在确定所述兑现请求有效时，所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中。
在一实施例中，所述若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息，并将所述加密交易限制信息发送至所述服务端的步骤包括：
若检测到基于所述权益凭证发起的兑现请求，则获取所述权益凭证的兑现附言，并基于所述兑现附言和预设块高，生成对应的交易限制信息；
获取所述服务端的数据公钥，并使用所述数据公钥对所述交易限制信息进行加密，以得到所述加密交易限制信息，并将所述加密交易限制信息发送至所述服务端。
在一实施例中，所述服务端在接收到所述加密交易限制信息时，基于所述加密交易限制信息，验证所述兑现请求是否有效，并在确定所述兑现请求有效时，所述服务端将所述 加密交易限制信息上传至所述区块链的合约数据表中的步骤包括：
所述服务端在接收到所述加密交易限制信息时，使用所述数据公钥对应的数据私钥解密所述加密交易限制信息，以得到所述交易限制信息；
所述服务端验证所述交易限制信息的所述兑现附言是否合理；
若所述服务端确定所述兑现附言合理，则使用所述服务端的签名私钥对所述加密交易限制信息进行签名，生成所述第二数字签名，并将所述第二数字签名和所述加密交易限制信息上传至所述区块链的合约数据表中。
在一实施例中，所述若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息，并将所述加密交易限制信息发送至所述服务端的步骤包括：
若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息和所述权益凭证的零知识证明，并将所述加密交易限制信息和所述零知识证明发送至所述服务端；
所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中的步骤包括：
所述服务端将所述加密交易限制信息和所述零知识证明上传至所述区块链，由所述区块链基于所述零知识证明验证所述权益凭证的兑现记录；
其中，若验证通过，则所述区块链标记所述权益凭证的兑现记录为已兑现，并将所述加密交易限制信息保存在所述合约数据表中。
在一实施例中，所述若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息，并将所述加密交易限制信息发送至所述服务端的步骤之前，所述凭证验证方法还包括：
若检测到基于所述权益凭证发起的购买请求，则将预设的验证密钥发送至所述服务端；
接收所述服务端基于所述购买请求发送的所述权益凭证对应的全局唯一加密凭证、所述服务端的签名公钥和所述全局唯一加密凭证的第一数字签名，并核实所述区块链的合约数据表中是否存在所述全局唯一加密凭证、所述签名公钥和所述第一数字签名，其中，所述服务端基于所述验证密钥和所述权益凭证对应的服务项目生成所述全局唯一加密凭证，并使用所述签名公钥对所述全局唯一加密凭证进行签名，以得到所述第一数字签名；
若存在，则确定所述权益凭证购买完成。
在一实施例中，所述服务端基于所述验证密钥和所述权益凭证对应的服务项目生成所述全局唯一加密凭证的步骤包括：
所述服务端在接收到所述验证密钥时，基于所述验证密钥和所述权益凭证对应的服务项目，生成对应的服务承诺；
所述服务端基于所述服务承诺和所述区块链的服务标识，生成所述全局唯一加密凭 证。
此外，为实现上述目的，本申请还提供一种凭证验证装置，所述凭证验证装置包括：
检测模块，用于若检测到基于权益凭证发起的验证请求，则从所述验证请求对应的区块链的合约数据表中，获取所述权益凭证的服务内容和所述权益凭证的兑现记录；
验证模块，用于获取所述权益凭证的验证密钥、所述权益凭证的服务项目以及所述权益凭证对应的服务端的签名公钥，并基于所述验证密钥、所述服务项目和所述签名公钥，验证所述服务内容；
所述验证模块，还用于若所述服务内容验证通过，则获取所述权益凭证的兑现附言，并基于所述兑现附言，验证所述兑现记录；
确定模块，用于若所述兑现记录验证通过，则确定所述权益凭证有效。
在一实施例中，所述服务内容包括服务承诺、服务标识和第一数字签名，所述验证模块还用于：
基于所述验证密钥和所述服务项目，计算对应的待验证承诺，并确定所述待验证承诺是否与所述服务承诺一致；
若是，则使用所述签名公钥验证所述第一数字签名是否是对全局唯一加密凭证的有效签名，若是，则确定所述服务内容验证通过，其中，所述全局唯一加密凭证由所述服务承诺和所述服务标识生成。
在一实施例中，所述兑现记录包括加密交易限制信息和第二数字签名，所述验证模块还用于：
基于所述兑现附言，验证所述加密交易限制信息是否正确；
若正确，则使用所述签名公钥验证所述第二数字签名是否是对所述加密交易限制信息的有效签名，若是，则确定所述兑现记录验证通过。
在一实施例中，所述检测模块还用于：
若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息，并将所述加密交易限制信息发送至所述服务端；
检测所述区块链的合约数据表中是否存在所述加密交易限制信息，若存在，则确定所述权益凭证完成兑现；
其中，所述服务端在接收到所述加密交易限制信息时，基于所述加密交易限制信息，验证所述兑现请求是否有效，并在确定所述兑现请求有效时，所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中。
在一实施例中，所述检测模块还用于：
若检测到基于所述权益凭证发起的兑现请求，则获取所述权益凭证的兑现附言，并基于所述兑现附言和预设块高，生成对应的交易限制信息；
获取所述服务端的数据公钥，并使用所述数据公钥对所述交易限制信息进行加密，以得到所述加密交易限制信息，并将所述加密交易限制信息发送至所述服务端。
在一实施例中，所述服务端在接收到所述加密交易限制信息时，基于所述加密交易限制信息，验证所述兑现请求是否有效，并在确定所述兑现请求有效时，所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中的步骤包括：
所述服务端在接收到所述加密交易限制信息时，使用所述数据公钥对应的数据私钥解密所述加密交易限制信息，以得到所述交易限制信息；
所述服务端验证所述交易限制信息的所述兑现附言是否合理；
若所述服务端确定所述兑现附言合理，则使用所述服务端的签名私钥对所述加密交易限制信息进行签名，生成所述第二数字签名，并将所述第二数字签名和所述加密交易限制信息上传至所述区块链的合约数据表中。
在一实施例中，所述检测模块还用于：
若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息和所述权益凭证的零知识证明，并将所述加密交易限制信息和所述零知识证明发送至所述服务端；
所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中的步骤包括：
所述服务端将所述加密交易限制信息和所述零知识证明上传至所述区块链，由所述区块链基于所述零知识证明验证所述权益凭证的兑现记录；
其中，若验证通过，则所述区块链标记所述权益凭证的兑现记录为已兑现，并将所述加密交易限制信息保存在所述合约数据表中。
在一实施例中，所述检测模块还用于：
若检测到基于所述权益凭证发起的购买请求，则将预设的验证密钥发送至所述服务端；
接收所述服务端基于所述购买请求发送的所述权益凭证对应的全局唯一加密凭证、所述服务端的签名公钥和所述全局唯一加密凭证的第一数字签名，并核实所述区块链的合约数据表中是否存在所述全局唯一加密凭证、所述签名公钥和所述第一数字签名，其中，所述服务端基于所述验证密钥和所述权益凭证对应的服务项目生成所述全局唯一加密凭证，并使用所述签名公钥对所述全局唯一加密凭证进行签名，以得到所述第一数字签名；
若存在，则确定所述权益凭证购买完成。
在一实施例中，所述检测模块还用于：
所述服务端在接收到所述验证密钥时，基于所述验证密钥和所述权益凭证对应的服务项目，生成对应的服务承诺；
所述服务端基于所述服务承诺和所述区块链的服务标识，生成所述全局唯一加密凭 证。
此外，为实现上述目的，本申请还提供一种凭证验证设备，所述凭证验证设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的凭证验证程序，所述凭证验证程序被所述处理器执行时实现如上所述的凭证验证方法的步骤。
此外，为实现上述目的，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有凭证验证程序，所述凭证验证程序被处理器执行时实现如上所述的凭证验证方法的步骤。
本申请提出的凭证验证方法，若检测到基于权益凭证发起的验证请求，则从所述验证请求对应的区块链的合约数据表中，获取所述权益凭证的服务内容和所述权益凭证的兑现记录；获取所述验证请求的验证密钥、所述权益凭证的服务项目以及所述权益凭证对应的服务端的签名公钥，并基于所述验证密钥、所述服务项目和所述签名公钥，验证所述服务内容；若所述服务内容验证通过，则获取所述权益凭证的兑现附言，并基于所述兑现附言，验证所述兑现记录；若所述兑现记录验证通过，则确定所述权益凭证有效。本申请的权益凭证验证不需要服务端参与，利用区块链的不可篡改的特性，从区块链中下载相应的证明，来证实权益凭证有效，实现自主验证，并且，在验证过程中，需要验证密钥，也即在购买之初，采用密码学技术对其进行了加密，因此，第三方无法获知并验证权益凭证的内容，从而保护了服务提供方的商业机密和买方的个人隐私。
附图说明
图1是本申请实施例方案涉及的硬件运行环境的设备结构示意图；
图2为本申请凭证验证方法第一实施例的流程示意图。
本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
如图1所示，图1是本申请实施例方案涉及的硬件运行环境的设备结构示意图。
本申请实施例设备可以是PC机或服务器设备。
如图1所示，该设备可以包括：处理器1001，例如CPU，网络接口1004，用户接口1003，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处 理器1001的存储装置。
本领域技术人员可以理解，图1中示出的设备结构并不构成对设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及凭证验证程序。
操作系统是管理和控制凭证验证设备与软件资源的程序，支持网络通信模块、用户接口模块、凭证验证程序以及其他程序或软件的运行；网络通信模块用于管理和控制网络接口1002；用户接口模块用于管理和控制用户接口1003。
在图1所示的凭证验证设备中，所述凭证验证设备通过处理器1001调用存储器1005中存储的凭证验证程序，并执行下述凭证验证方法各个实施例中的操作。
基于上述硬件结构，提出本申请凭证验证方法实施例。
参照图2，图2为本申请凭证验证方法第一实施例的流程示意图，所述方法包括：
步骤S10，若检测到基于权益凭证发起的验证请求，则从所述验证请求对应的区块链的合约数据表中，获取所述权益凭证的服务内容和所述权益凭证的兑现记录；
步骤S20，获取所述验证请求的验证密钥、所述权益凭证的服务项目以及所述权益凭证对应的服务端的签名公钥，并基于所述验证密钥、所述服务项目和所述签名公钥，验证所述服务内容；
步骤S30，若所述服务内容验证通过，则获取所述权益凭证的兑现附言，并基于所述兑现附言，验证所述兑现记录；
步骤S40，若所述兑现记录验证通过，则确定所述权益凭证有效。
本实施例凭证验证方法运用于理财机构或者银行等金融机构的凭证验证设备中，凭证验证设备可以是终端、机器人或者PC设备，为描述方便，凭证验证设备以凭证设备进行描述，在具体实施时，凭证设备可以是金融机构内部员工所使用的设备，也可以是金融机构对外发行的软硬件系统，由用户自行安装在自己的终端设备上所形成的凭证设备等。凭证设备可通过网络通讯与服务端对接，并且凭证设备与服务端存在区块链，其中，服务端为权益凭证的服务提供方，负责对外发售相关的权益凭证，而持有凭证设备的用户为买方，可通过网络通讯向服务端购买或者兑现权益凭证，并能自主验证权益凭证，而区块链则记录凭证设备与服务端之间的交易行为。
本实施例的凭证设备，在检测到基于权益凭证发起的验证请求时，从区块链的合约数据表中下载验证所需的服务内容和兑现记录，并依次验证服务内容和兑现记录，若两者都验证通过，则确定权益凭证有效，即，权益凭证为有效证据，可通过权益凭证进行追责，验证过程中，由于区块链不可篡改的特性，无需服务端参与，凭证设备自主就能完成。
以下将对各个步骤进行详细说明：
步骤S10，若检测到基于权益凭证发起的验证请求，则从所述验证请求对应的区块链的合约数据表中，获取所述权益凭证的服务内容和所述权益凭证的兑现记录。
在本实施例中，若是遇到纠纷，或者买方需要取得权益凭证的公开验证，则可以通过凭证设备发起验证请求，在具体实施时，凭证设备可以是买方的手机等移动终端。
若凭证设备检测到基于权益凭证发起的验证请求，则从验证请求对应的区块链的合约数据表中下载权益凭证对应的服务内容和兑现记录，也即区块链的合约数据表中记录有凭证设备与服务端之间的交易行为，具体包括服务内容和兑现记录，其中，服务内容是权益凭证对应的服务项目，即权益凭证对应的具体服务是什么，而兑现记录则是权益凭证是否兑现。由于区块链不可篡改的特性，因此，凭证设备从区块链中下载相关的服务内容和兑现记录更具公正性，也能确保相关数据真实。
步骤S20，获取所述权益凭证的验证密钥、所述权益凭证的服务项目以及所述权益凭证对应的服务端的签名公钥，并基于所述验证密钥、所述服务项目和所述签名公钥，验证所述服务内容。
在本实施例中，凭证设备依次对服务内容和兑现进行进行验证，首先，在对服务内容进行验证时，需要先获取验证密钥，其中，验证密钥为买方在购买当前权益凭证时所预设的一个密钥，即验证密钥原则上只有买方知道，因此，在具体实施时，凭证设备可通过接收买方输入的验证密钥来获取权益凭证的验证密钥，接着，获取权益凭证的服务项目，以及权益凭证对应的服务端的签名公钥，其中，签名公钥在区块链上可知，因此，连接区块链的凭证设备可以获取到，然后，凭证设备根据验证密钥、服务项目和签名公钥验证服务内容。
具体的，所述服务内容包括服务承诺、服务标识和第一数字签名，步骤S20包括：
步骤a，基于所述验证密钥和所述服务项目，计算对应的待验证承诺，并确定所述待验证承诺是否与所述服务承诺一致；
在该步骤中，凭证设备具体从区块链的合约数据表中下载下来的服务内容包括服务承诺、服务标识和第一数字签名，在对服务内容进行验证的过程中，用验证密钥和服务项目，计算待验证承诺，并确定待验证承诺是否与从区块链的合约数据表中下载下来的服务承诺一致。
待验证承诺的计算具体为：
获取第一公开参数G和第二公开参数H，并基于所述验证密钥、所述服务项目、所述第一公开参数、所述第二公开参数和预设公式，计算对应的待验证承诺，并确定所述待验证承诺是否与所述服务承诺一致。
在该步骤中，凭证设备获取第一公开参数G和第二公开参数H，其中，G和H为事先公开的参数，在具体实施时，由监管仲裁方通过可信的信道公开，因此，凭证设备可获 取到，然后，根据验证密钥、服务项目、预设公式，G和H，计算待验证承诺。
在本实施例中，预设公式优选为椭圆曲线公式，即待验证承诺＝验证密钥r*第一公开参数G+Encode(服务项目)*第二公开参数H，其中，Encode是公开的编码函数，在这里，是将服务项目转换成数值。
在另一实施例中，为了通用性考虑，对于非整数类型的服务项目的服务项目的值，可以使用哈希函数Hash作为Encode函数。
需要说明的是，服务承诺是买方通过凭证设备购买权益凭证时，通过上述计算方法得出，并储存在区块链的合约数据表中，因此，只需验证当前计算得出的待验证承诺是否与区块链的合约数据表中的服务承诺一致。
步骤b，若是，则使用所述签名公钥验证所述第一数字签名是否是对全局唯一加密凭证的有效签名，若是，则确定所述服务内容验证通过，其中，所述全局唯一加密凭证由所述服务承诺和所述服务标识生成。
若确定计算所得待验证承诺与在区块链的合约数据表中下载下来的服务承诺一致，则进一步使用服务端的签名公钥验证第一数字签名是否是全局唯一加密凭证的有效签名，也即验证服务端是否知道并承认过当前权益凭证，需要解释的是第一数字签名由服务端使用签名私钥对全局唯一加密凭证进行签名所得，因此，需要使用服务端的签名公钥进行验证。
可以理解的，全局唯一加密凭证可以由服务承诺单独生成，也即在验证之前，由服务端计算得到当前权益凭证的服务承诺(具体计算方法与上述计算待验证承诺类似，并且验证密钥由买方通过凭证设备发送给服务端)，并使用签名私钥对服务承诺进行签名，从而得到第一数字签名，但由于在极小概率下可能出现r与Encode(服务项目)的值相同，导致两个权益凭证的服务承诺相同的情况，为了防止此种情况发生，本实施例优选引入一个全局唯一的标识号——服务标识，在验证之前，服务端用服务承诺和服务标识组成全局唯一加密凭证，并对其签名，以得到第一数字签名，服务标识是一个全局的只增不减的单增序列数，对任一条历史记录中的服务标识一旦生成，不会对同一个表内数据的删减而改变，服务标识的获取可以利用区块链智能合约执行的事务原子性获得，这里不再详述，而凭证设备在验证过程中获取到的服务标识，是从区块链的合约数据表中下载下来的。
步骤S30，若所述服务内容验证通过，则获取所述权益凭证的兑现附言，并基于所述兑现附言，验证所述兑现记录。
在本实施例中，若凭证设备确定权益凭证的服务内容验证通过，则进一步获取权益凭证的兑现附言，其中，兑现附言是指买方在购买当前权益凭证时所设置的，并且是服务端的服务提供方认可的信息，如当前权益凭证可在服务提供方指定的301-501号店使用，买方在购买之初可通过凭证设备设置“在301号店使用”作为兑现附言，然后，凭证设备基于当前权益凭证的兑现附言，验证权益凭证在区块链中的兑现记录。
具体的，所述兑现记录包括加密交易限制信息和第二数字签名，步骤S30包括：
步骤c，基于所述兑现附言，验证所述加密交易限制信息是否正确；
在该步骤中，凭证设备根据当前权益凭证的兑现附言，验证加密交易限制信息是否正确，具体的验证过程为：
获取所述服务端的数据公钥，以及所述权益凭证对应的预设块高，基于所述兑现附言、所述预设块高和所述数据公钥，验证所述加密交易限制信息是否正确。
具体的，在验证之前，凭证设备获取兑现附言和预设块高，并基于兑现附言和预设块高生成交易限制信息，也即，交易限制信息＝(预设块高，兑现附言)，接着，使用服务端的数据公钥对交易限制信息进行加密，得到加密交易限制信息，因此，在验证过程中，只需验证E_condition＝E_PK_data_s(maxBlockNumber,claimMessage)是否成立，其中，E_condition为加密交易限制信息，maxBlockNumber为预设块高，claimMessage为兑现附言，PK_data_s为服务端的数据公钥，也即验证加密交易限制信息的明文是否与密文对应上。
步骤d，若正确，则使用所述签名公钥验证所述第二数字签名是否是对所述加密交易限制信息的有效签名，若是，则确定所述兑现记录验证通过。
若E_condition＝E_PK_data_s(maxBlockNumber,claimMessage)的等式成立，即加密交易限制信息验证正确，则使用服务端的签名公钥，验证第二数字签名是否是对加密交易限制信息的有效签名，也即确定服务端是否知道并承认过加密交易限制信息，其中，第二数字签名为服务端使用其签名私钥对加密交易限制信息进行签名所得，因此，凭证设备用签名公钥来验证第二数字签名是否是对加密交易限制信息的有效签名。
若第二数字签名是对加密交易限制信息的有效签名，则确定兑现记录验证通过。
步骤S40，若所述兑现记录验证通过，则确定所述权益凭证有效。
在本实施例中，若凭证设备确定当前权益凭证的服务内容和兑现记录都验证通过，则确定当前权益凭证有效，可作为证据向监管仲裁方展示。
可以理解的，若服务内容和/或兑现记录验证不通过，则确定当前权益凭证无效，不能作为证据进行追责。
本实施例若检测到基于权益凭证发起的验证请求，则从所述验证请求对应的区块链的合约数据表中，获取所述权益凭证的服务内容和所述权益凭证的兑现记录；获取所述验证请求的验证密钥、所述权益凭证的服务项目以及所述权益凭证对应的服务端的签名公钥，并基于所述验证密钥、所述服务项目和所述签名公钥，验证所述服务内容；若所述服务内容验证通过，则获取所述权益凭证的兑现附言，并基于所述兑现附言，验证所述兑现记录；若所述兑现记录验证通过，则确定所述权益凭证有效。本申请的权益凭证验证不需要服务端参与，利用区块链的不可篡改的特性，从区块链中下载相应的证明，来证实权益凭证有 效，实现自主验证，并且，在验证过程中，需要验证密钥，也即在购买之初，采用密码学技术对其进行了加密，因此，第三方无法获知并验证权益凭证的内容，从而保护了服务提供方的商业机密和买方的个人隐私。
进一步地，基于本申请凭证验证方法第一实施例，提出本申请凭证验证方法第二实施例。
凭证验证方法的第二实施例与凭证验证方法的第一实施例的区别在于，步骤S10之前，凭证验证方法还包括：
步骤S50，若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息，并将所述加密交易限制信息发送至所述服务端；
步骤S60，检测所述区块链的合约数据表中是否存在所述加密交易限制信息，若存在，则确定所述权益凭证完成兑现；
其中，所述服务端在接收到所述加密交易限制信息时，基于所述加密交易限制信息，验证所述兑现请求是否有效，并在确定所述兑现请求有效时，所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中。
本实施例若检测到基于权益凭证发起的兑现请求，则需要将加密交易限制信息发给服务端，而服务端将加密交易限制信息上传至区块链的合约数据表中，当在区块链的合约数据表中检测到加密交易限制信息时，确定权益凭证兑现完成。
以下将对各个步骤进行详细说明：
步骤S50，若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息，并将所述加密交易限制信息发送至所述服务端。
在本实施例中，若凭证设备检测到基于权益凭证发起的兑现请求，则确定权益凭证的加密交易限制信息，并将该加密交易限制信息发送至服务端，也即，买方通过凭证设备兑现权益凭证时，需确定权益凭证的加密交易限制信息，再将加密交易限制信息发送给服务端，以供服务端进行确认，可以理解的，权益凭证是由服务端发行的，在买方持有权益凭证，并且需要兑现时，需要向服务端进行兑现，而兑现所需证明，则为加密交易限制信息。
其中，步骤S50包括：
步骤e，若检测到基于所述权益凭证发起的兑现请求，则获取所述权益凭证的兑现附言，并基于所述兑现附言和预设块高，生成对应的交易限制信息；
在该步骤中，若凭证设备检测到基于权益凭证发起的兑现请求，则获取权益凭证的兑现附言，并根据兑现附言和预设块高，生成对应的交易限制信息，其中，预设块高为凭证设备根据当前区块链节点对应的块高，加上一个合理上限，如当前区块链节点的块高+10，即为预设块高，合理上限可根据实际情况进行调整，可以理解的，区块链节点的块高随交易的产生而不断增加，为保证交易的安全性，需要设置一个合理上限，确保后续区块链在 验证兑现记录时，当前区块链节点的块高不会超过预设块高，类似现有手机验证码的有效时间，在有效时间内才能进行验证。而兑现附言则可以是任意服务端认可的信息，如当前权益凭证“在301号店使用”，最后生成condition＝(maxBlockNumber，claimMessage)，其中，condition为交易限制信息，maxBlockNumber为预设块高，claimMessage为兑现附言。
步骤f，获取所述服务端的数据公钥，并使用所述数据公钥对所述交易限制信息进行加密，以得到所述加密交易限制信息，并将所述加密交易限制信息发送至所述服务端。
接着，凭证设备获取服务端的数据公钥，该数据公钥在区块链中可知，并使用数据公钥对交易限制信息进行加密，从而得到加密交易限制信息，并将加密交易限制信息发送给服务端。
步骤S60，检测所述区块链的合约数据表中是否存在所述加密交易限制信息，若存在，则确定所述权益凭证完成兑现；
所述服务端在接收到所述加密交易限制信息时，基于所述加密交易限制信息，验证所述兑现请求是否有效，并在确定所述兑现请求有效时，所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中。
在本实施例中，凭证设备在将加密交易限制信息发送给服务端后，只需在区块链的合约数据表中确定是否存在与发给服务端一致的加密交易限制信息，若存在，则确定当前权益凭证兑现完成。
其中，具体的，交易流程为：凭证设备将加密交易限制信息发送给服务端，服务端在接收到加密交易限制信息时，根据加密交易限制信息，验证凭证设备发起的兑现请求是否有效，具体确定当前权益凭证是否有效，当前权益凭证是否未被兑现等，并在确定兑现请求有效时，服务端才将加密交易限制信息上传至区块链的合约数据表中。
进一步的，在服务端将加密交易限制信息上传至区块链的合约数据表中的过程中，包括：
步骤g，所述服务端在接收到所述加密交易限制信息时，使用所述数据公钥对应的数据私钥解密所述加密交易限制信息，以得到所述交易限制信息；
在该步骤中，由于加密交易限制信息加密时用的是服务端的数据公钥，因此，服务端在接收到加密交易限制信息时，使用对应的数据私钥对加密交易限制信息进行解密，从而得到交易限制信息，由于交易限制信息由兑现附言和预设块高组成，因此也即得到当前权益凭证对应的预设块高和兑现附言。
步骤h，所述服务端验证所述交易限制信息的所述兑现附言是否合理；
接着，服务端验证兑现附言是否合理，具体验证过程为：
将兑现附言与服务端对应的预设兑现附言进行比较，确定兑现附言是否在预设兑现附 言中，如，服务端针对权益凭证预设的兑现附言为“在301-501号店使用”，那么当兑现附言在301-501号店之间，如“在302号店使用”，则认为兑现附言合理。
步骤i，若所述服务端确定所述兑现附言合理，则使用所述服务端的签名私钥对所述加密交易限制信息进行签名，生成所述第二数字签名，并将所述第二数字签名和所述加密交易限制信息上传至所述区块链的合约数据表中。
服务端在确定兑现附言合理后，需要留下证据，证明自己知道并承认过加密交易限制信息，因此，服务端使用签名私钥对加密交易限制信息进行签名，生成第二数字签名，最后，将加密交易限制信息和第二数字签名上传至区块链的合约数据表中。
本实施例为后续能准确的验证权益凭证，在兑现权益凭证时，需要将加密交易限制信息作为证据发送给服务端，以供服务端签名，再由服务端上传至区块链的合约数据表中，使得后续凭证设备从区块链的合约数据表中下载下来的信息是可信的，服务端无法抵赖的，从而提高权益凭证的自主验证的可行性。
进一步地，基于本申请凭证验证方法第一、第二实施例，提出本申请凭证验证方法第三实施例。
凭证验证方法的第三实施例与凭证验证方法的第一、第二实施例的区别在于，步骤S50包括：
步骤j，若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息和所述权益凭证的零知识证明，并将所述加密交易限制信息和所述零知识证明发送至所述服务端；
所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中的步骤包括：
步骤k，所述服务端将所述加密交易限制信息和所述零知识证明上传至所述区块链，由所述区块链基于所述零知识证明验证所述权益凭证的兑现记录；
其中，若验证通过，则所述区块链标记所述权益凭证的兑现记录为已兑现，并将所述加密交易限制信息保存在所述合约数据表中。
本实施例凭证设备在将权益凭证的加密交易限制信息发送给服务端时，还一并把零知识证明发送过去，以便服务端将加密交易限制信息和零知识证明上传至区块链时，区块链基于零知识证明验证当前权益凭证的兑现记录，若验证通过，才将加密交易限制信息保存在合约数据表中，此时，权益凭证的兑现才完成。
以下将对各个步骤进行详细说明：
步骤j，若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息和所述权益凭证的零知识证明，并将所述加密交易限制信息和所述零知识证明发送至所述服务端。
在本实施例中，在买方通过凭证设备购买到权益凭证后，可以通过凭证设备向服务端 提供证明自己知道验证密钥来兑现相应的服务项目，但由于区块链在交易生效前需要广播证明数据的明文，也即需将验证密钥广播，然而，若是将验证密钥广播出去，将给买方带来损失，因此，不能直接广播验证密钥的明文来完成兑现，在本实施例中，使用绑定加密交易限制信息的零知识证明来解决这一问题。
需要解释的是，零知识证明zk_proof(zero-knowledge proof)指的是证明者能够在不向验证者提供任何有用的信息的情况下，使验证者相信某个论断是正确的。零知识证明实质上是一种涉及两方或更多方的协议，即两方或更多方完成一项任务所需采取的一系列步骤。证明者向验证者证明并使其相信自己知道或拥有某一消息，但证明过程不能向验证者泄漏任何关于被证明消息的信息。
在这里，若凭证设备检测到基于权益凭证发起的兑现请求，则确定权益凭证的加密交易限制信息和零知识证明，其中，加密交易限制信息的确定可参见上一实施例，在此不再赘述，而零知识证明的确定过程，具体包括：
获取预设随机参数a和b，并获取所述权益凭证的服务承诺、服务项目和验证密钥，基于所述服务承诺、所述服务项目、所述验证密钥、所述随机参数a和b，生成零知识证明。
在该步骤中，买方通过凭证设备选取两个独立的随机参数a和b，并且不公开，只有买方知道，然后计算v_item_i＝Encode(item_i)，其中，v_item_i为项目数值，item_i为服务项目，接着计算z0＝hash(G||H||serviceCommitment||T1||E_condition)，其中，T1＝a*G+b*H，G和H为公开参数，serviceCommitment为服务承诺，E_condition为加密交易限制信息，而符号||表示字符串之后加上字符串，如A||B：指在A字符串之后附加B字符串，例如“ab”||“c”＝“abc”。
接着，计算z1＝a-z0*r，其中，r为验证密钥，接着，计算z2＝b-z0*v_item_i，最后，通过z0、z1、z2组成零知识证明，即零知识证明zk_proof＝(z0,z1,z2)。
最后，凭证设备将加密交易限制信息和零知识证明发送给服务端。
需要说明的是，由于零知识证明的本意在于证明且不泄露自身的私密信息，因此，凭证设备可根据实际情况选择相应的参数来生成零知识证明。
进一步地，所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中的步骤包括：
步骤k，所述服务端将所述加密交易限制信息和所述零知识证明上传至所述区块链，由所述区块链基于所述零知识证明验证所述权益凭证的兑现记录；
若验证通过，则所述区块链标记所述权益凭证的兑现记录为已兑现，并将所述加密交易限制信息保存在所述合约数据表中。
在该步骤中，服务端同样需要核实兑现请求的有效性，具体步骤与上一实施例类似， 在此不再赘述。
在确定兑现请求有效时，服务端将加密交易限制信息和零知识证明上传至区块链中，由区块链基于零知识证明验证权益凭证的兑现记录。具体的验证过程包括：
确定等式T2＝z1*G+z2*H+z0*serviceCommitment是否成立，并在确定等式成立时，验证等式z0＝hash(G||H||serviceCommitment||T2||E_condition)是否成立，若验证通过，则区块链标记权益凭证的兑现记录为已兑现，并将所述加密交易限制信息保存在所述合约数据表中，具体的，在验证通过后，区块链通过智能合约产生一个交易，并进行以下操作：
标记权益凭证在合约数据表中对应的记录为已兑现，具体附加一个Used标记字段，再将加密交易限制信息和第二数字签名保存在合约数据表中。
需要说明的是，买方的在购买权益凭证时，区块链就已记录了相关的交易信息，包括服务承诺和服务标识，因此，在将权益凭证在合约数据表中对应的记录标记为已兑现时，实际是标记(serviceCommitment,serviceId)为已兑现。
进一步地，在区块链验证兑现记录过程中，还包括：
确定serviceCommitment，serviceId是否存在于T_coupon合约数据表中，且未被兑现，没有发现Used标记字段，并且兑现记录中的签名公钥PK_sig_s’与兑现请求中的签名公钥PK_sig_s相同，同时，当前区块链节点的块高没有超过预设块高maxBlockNumber。然后才去计算等式T2＝z1*G+z2*H+z0*serviceCommitment是否成立，验证等式z0＝hash(G||H||serviceCommitment||T2||E_condition)是否成立。
本实施例在权益凭证兑现过程中，为避免验证密钥被区块链广播，采用零知识证明来证明兑现请求的有效性，使得兑现过程安全且隐秘，在后续验证过程中不会被人轻易破解，使得后续的验证过程更加安全可信，提高权益凭证自主验证的可行性。
进一步地，基于本申请凭证验证方法第一、第二、第三实施例，提出本申请凭证验证方法第四实施例。
凭证验证方法的第四实施例与凭证验证方法的第一、第二、第三实施例的区别在于，步骤S50之前，凭证验证方法还包括：
步骤S70，若检测到基于所述权益凭证发起的购买请求，则将预设的验证密钥发送至所述服务端；
步骤S80，接收所述服务端发送的所述权益凭证对应的全局唯一加密凭证、所述服务端的签名公钥和所述全局唯一加密凭证的第一数字签名，并核实所述区块链中是否存在所述全局唯一加密凭证、所述签名公钥和所述第一数字签名，其中，所述服务端基于所述验证密钥和所述权益凭证对应的服务项目生成所述全局唯一加密凭证，并使用所述签名公钥对所述全局唯一加密凭证进行签名，以得到所述第一数字签名；
若存在，则确定所述权益凭证购买完成。
本实施例若检测到基于权益凭证发起的购买请求，区块链会记录本次交易，因此，只需检测区块链中是否存在相应的记录即可确定购买完成。
具体的：步骤S70，若检测到基于所述权益凭证发起的购买请求，则将预设的验证密钥发送至所述服务端。
在本实施例中，若凭证设备检测到买方基于权益凭证发起的购买请求，则将预设的验证密钥发送至服务端，其中，预设密钥是买方选取的随机数，可以理解的，本次交易必然涉及金钱，由于金钱对后续的验证没有贡献，在此省略不提。
步骤S80，接收所述服务端基于所述购买请求发送的所述权益凭证对应的全局唯一加密凭证、所述服务端的签名公钥和所述全局唯一加密凭证的第一数字签名，并核实所述区块链中是否存在所述全局唯一加密凭证、所述签名公钥和所述第一数字签名，其中，所述服务端基于所述验证密钥和所述权益凭证对应的服务项目生成所述全局唯一加密凭证，并使用所述签名公钥对所述全局唯一加密凭证进行签名，以得到所述第一数字签名；
若存在，则确定所述权益凭证购买完成。
在本实施中，凭证设备接收服务端基于购买请求发送的当前权益凭证对应的全局唯一加密凭证，服务端的签名公钥和全局唯一加密凭证的第一数字签名，并且去区块链中核实是否存在一样的全局唯一加密凭证，服务端的签名公钥和第一数字签名，若存在，则确定权益凭证购买完成。
在凭证设备将验证密钥发送至服务端之后，服务端根据验证密钥和权益凭证对应的服务项目生成全局唯一加密凭证，再使用服务端的签名公钥对全局唯一加密凭证进行签名，从而得到第一数字签名，再将全局唯一加密凭证和第一数字签名返回给凭证设备。
具体的，所述服务端基于所述验证密钥和所述权益凭证对应的服务项目生成所述全局唯一加密凭证的步骤包括：
步骤l，所述服务端在接收到所述验证密钥时，基于所述验证密钥和所述权益凭证对应的服务项目，生成对应的服务承诺；
步骤m，所述服务端基于所述服务承诺和所述区块链的服务标识，生成所述全局唯一加密凭证。
服务端根据验证密钥和第一公开参数G，计算rG＝r*G，r为验证密钥，G为公开参数中椭圆曲线上的第一公开参数，*是椭圆曲线上的标量乘法运算，例如3*G＝G+G+G，其中，需要说明的是，rG也可以由凭证设备计算并发送至服务端。
接着，服务端计算服务项目的整数表达值——服务项目数值v_item_i＝Encode(item_i)，其中，Encode是公开的编码函数，目的自安于将item_i转化成数值类型，因此也可用哈希函数Hash代替。
接着，服务端计算私密承诺serviceCommitment＝rG+v_item_i*H，再使用签名私钥对 私密承诺进行签名，当然，为避免出现两个服务承诺相同的情况，服务端还需调用区块链的智能合约接口，获得一个全局唯一的标识号——服务标识，同时，为使得下一服务标识与当前服务标识区别，更新区块链上下一服务标识，具体使得下一服务标识+1，即服务标识serviceId是一个全局的只增不减的单增序列数，对任一条历史记录中的serviceId一旦生成，不会因对同一个表内数据的删减而改变。serviceId可以很容易利用区块链智能合约执行的事务原子性获得，这里不再详述。
服务端再通过服务承诺和服务标识，生成全局唯一加密凭证，即unique_c＝(serviceCommitment,serviceId)，其中，unique_c为全局唯一加密凭证，服务端再使用其签名私钥对unique_c进行签名，生成第一数字签名：Sig_c＝Sig_SK_sig_s(unique_c)，其中，Sig_c为第一数字签名，SK_sig_s为服务端的签名私钥。
最后，服务端调用区块链智能合约接口，将(unique_c,PK_sig_s,Sig_c)保存到未被兑现的合约数据表中，也即，相关记录没有附加Used标记字段，基于区块链不可篡改特性，每一次对合约数据表的操作都会留下不可更改的记录。
进一步地，凭证设备核实区块链的合约数据表中是否存在全局唯一加密凭证、服务端的签名公钥和第一数字签名的具体过程为：
凭证设备计算serviceCommitment’＝rG+Encode(item_i)，其中，serviceCommitment’为待验证承诺，再从unique_c中提取serviceCommitment，验证serviceCommitment’是否等于serviceCommitment；若验证通过，则继续验证服务端的数字证书，验证服务端与签名公钥的关联关系，即确定服务端知道并承认过权益凭证，具体的，服务端在对外发行权益凭证之前，需向监管仲裁方发送签名公钥和相关证明材料，如营业执照等，登记申请自己的数字证书，监管仲裁方核实服务端的身份，并用CA的根证书为服务端颁发对应的数字证书，监管仲裁方保存以上颁发的数字证书和服务端真实身份的对应关系，事后可以通过验证证书中的签名公私钥来确定服务端的身份。
凭证设备接着去区块链的合约数据表中核实unique_c,PK_sig_s,Sig_c是否存在，若存在，凭证设备则向服务端发送确认消息，确认已收到正确的权益凭证，否则联系服务端进行更正，具体可向服务端发送错误消息，以及错误对象，即哪一证明参数不对，以供服务端进行更正。
本实施例在购买权益凭证的过程中，使用凭证设备的验证密钥等，对权益凭证的交易信息进行加密，隐匿了权益凭证的内容，从而保护服务提供方的商业机密和买方的个人隐私，并且将服务端的签名公钥等作为交易证据上传至区块链，使得服务端无法抵赖曾经出售过相关的权益凭证，提高后续权益凭证自主验证的可行性。
本申请还提供一种凭证验证装置。本申请凭证验证装置包括：
检测模块，用于若检测到基于权益凭证发起的验证请求，则从所述验证请求对应的区 块链的合约数据表中，获取所述权益凭证的服务内容和所述权益凭证的兑现记录；
验证模块，用于获取所述权益凭证的验证密钥、所述权益凭证的服务项目以及所述权益凭证对应的服务端的签名公钥，并基于所述验证密钥、所述服务项目和所述签名公钥，验证所述服务内容；
所述验证模块，还用于若所述服务内容验证通过，则获取所述权益凭证的兑现附言，并基于所述兑现附言，验证所述兑现记录；
确定模块，用于若所述兑现记录验证通过，则确定所述权益凭证有效。
进一步地，所述服务内容包括服务承诺、服务标识和第一数字签名，所述验证模块还用于：
基于所述验证密钥和所述服务项目，计算对应的待验证承诺，并确定所述待验证承诺是否与所述服务承诺一致；
若是，则使用所述签名公钥验证所述第一数字签名是否是对全局唯一加密凭证的有效签名，若是，则确定所述服务内容验证通过，其中，所述全局唯一加密凭证由所述服务承诺和所述服务标识生成。
进一步地，所述兑现记录包括加密交易限制信息和第二数字签名，所述验证模块还用于：
基于所述兑现附言，验证所述加密交易限制信息是否正确；
若正确，则使用所述签名公钥验证所述第二数字签名是否是对所述加密交易限制信息的有效签名，若是，则确定所述兑现记录验证通过。
进一步地，所述检测模块还用于：
若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息，并将所述加密交易限制信息发送至所述服务端；
检测所述区块链的合约数据表中是否存在所述加密交易限制信息，若存在，则确定所述权益凭证完成兑现；
所述服务端在接收到所述加密交易限制信息时，基于所述加密交易限制信息，验证所述兑现请求是否有效，并在确定所述兑现请求有效时，所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中。
进一步地，所述检测模块还用于：
若检测到基于所述权益凭证发起的兑现请求，则获取所述权益凭证的兑现附言，并基于所述兑现附言和预设块高，生成对应的交易限制信息；
获取所述服务端的数据公钥，并使用所述数据公钥对所述交易限制信息进行加密，以得到所述加密交易限制信息，并将所述加密交易限制信息发送至所述服务端。
进一步地，所述服务端在接收到所述加密交易限制信息时，基于所述加密交易限制信 息，验证所述兑现请求是否有效，并在确定所述兑现请求有效时，所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中的步骤包括：
所述服务端在接收到所述加密交易限制信息时，使用所述数据公钥对应的数据私钥解密所述加密交易限制信息，以得到所述交易限制信息；
所述服务端验证所述交易限制信息的所述兑现附言是否合理；
若所述服务端确定所述兑现附言合理，则使用所述服务端的签名私钥对所述加密交易限制信息进行签名，生成所述第二数字签名，并将所述第二数字签名和所述加密交易限制信息上传至所述区块链的合约数据表中。
进一步地，所述检测模块还用于：
若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息和所述权益凭证的零知识证明，并将所述加密交易限制信息和所述零知识证明发送至所述服务端；
所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中的步骤包括：
所述服务端将所述加密交易限制信息和所述零知识证明上传至所述区块链，由所述区块链基于所述零知识证明验证所述权益凭证的兑现记录；
若验证通过，则所述区块链标记所述权益凭证的兑现记录为已兑现，并将所述加密交易限制信息保存在所述合约数据表中。
进一步地，所述检测模块还用于：
若检测到基于所述权益凭证发起的购买请求，则将预设的验证密钥发送至所述服务端；
接收所述服务端基于所述购买请求发送的所述权益凭证对应的全局唯一加密凭证、所述服务端的签名公钥和所述全局唯一加密凭证的第一数字签名，并核实所述区块链的合约数据表中是否存在所述全局唯一加密凭证、所述签名公钥和所述第一数字签名，其中，所述服务端基于所述验证密钥和所述权益凭证对应的服务项目生成所述全局唯一加密凭证，并使用所述签名公钥对所述全局唯一加密凭证进行签名，以得到所述第一数字签名；
若存在，则确定所述权益凭证购买完成。
进一步地，所述检测模块还用于：
所述服务端在接收到所述验证密钥时，基于所述验证密钥和所述权益凭证对应的服务项目，生成对应的服务承诺；
所述服务端基于所述服务承诺和所述区块链的服务标识，生成所述全局唯一加密凭证。
本申请还提供一种计算机可读存储介质。
本申请计算机可读存储介质上存储有凭证验证程序，所述凭证验证程序被处理器执行 时实现如上所述的凭证验证方法的步骤。
其中，在所述处理器上运行的凭证验证程序被执行时所实现的方法可参照本申请凭证验证方法各个实施例，此处不再赘述。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。
上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。
以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书与附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (12)

  1. 一种凭证验证方法，其中，所述凭证验证方法包括如下步骤：
    若检测到基于权益凭证发起的验证请求，则从所述验证请求对应的区块链的合约数据表中，获取所述权益凭证的服务内容和所述权益凭证的兑现记录；
    获取所述权益凭证的验证密钥、所述权益凭证的服务项目以及所述权益凭证对应的服务端的签名公钥，并基于所述验证密钥、所述服务项目和所述签名公钥，验证所述服务内容；
    若所述服务内容验证通过，则获取所述权益凭证的兑现附言，并基于所述兑现附言，验证所述兑现记录；
    若所述兑现记录验证通过，则确定所述权益凭证有效。
  2. 如权利要求1所述的凭证验证方法，其中，所述服务内容包括服务承诺、服务标识和第一数字签名；
    所述基于所述验证密钥、所述服务项目和所述签名公钥，验证所述服务内容的步骤包括：
    基于所述验证密钥和所述服务项目，计算对应的待验证承诺，并确定所述待验证承诺是否与所述服务承诺一致；
    若是，则使用所述签名公钥验证所述第一数字签名是否是对全局唯一加密凭证的有效签名，若是，则确定所述服务内容验证通过，其中，所述全局唯一加密凭证由所述服务承诺和所述服务标识生成。
  3. 如权利要求1所述的凭证验证方法，其中，所述兑现记录包括加密交易限制信息和第二数字签名；
    所述基于所述兑现附言，验证所述兑现记录的步骤包括：
    基于所述兑现附言，验证所述加密交易限制信息是否正确；
    若正确，则使用所述签名公钥验证所述第二数字签名是否是对所述加密交易限制信息的有效签名，若是，则确定所述兑现记录验证通过。
  4. 如权利要求1-3任一项所述的凭证验证方法，其中，所述若检测到基于权益凭证发起的验证请求，则从所述验证请求对应的区块链的合约数据表中，获取所述权益凭证的服务内容和所述权益凭证的兑现记录的步骤之前，所述凭证验证方法还包括：
    若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息，并将所述加密交易限制信息发送至所述服务端；
    检测所述区块链的合约数据表中是否存在所述加密交易限制信息，若存在，则确定所述权益凭证完成兑现；
    其中，所述服务端在接收到所述加密交易限制信息时，基于所述加密交易限制信息，验证所述兑现请求是否有效，并在确定所述兑现请求有效时，所述服务端将所述加密交易 限制信息上传至所述区块链的合约数据表中。
  5. 如权利要求4所述的凭证验证方法，其中，所述若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息，并将所述加密交易限制信息发送至所述服务端的步骤包括：
    若检测到基于所述权益凭证发起的兑现请求，则获取所述权益凭证的兑现附言，并基于所述兑现附言和预设块高，生成对应的交易限制信息；
    获取所述服务端的数据公钥，并使用所述数据公钥对所述交易限制信息进行加密，以得到所述加密交易限制信息，并将所述加密交易限制信息发送至所述服务端。
  6. 如权利要求5所述的凭证验证方法，其中，所述服务端在接收到所述加密交易限制信息时，基于所述加密交易限制信息，验证所述兑现请求是否有效，并在确定所述兑现请求有效时，所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中的步骤包括：
    所述服务端在接收到所述加密交易限制信息时，使用所述数据公钥对应的数据私钥解密所述加密交易限制信息，以得到所述交易限制信息；
    所述服务端验证所述交易限制信息的所述兑现附言是否合理；
    若所述服务端确定所述兑现附言合理，则使用所述服务端的签名私钥对所述加密交易限制信息进行签名，生成所述第二数字签名，并将所述第二数字签名和所述加密交易限制信息上传至所述区块链的合约数据表中。
  7. 如权利要求4所述的凭证验证方法，其中，所述若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息，并将所述加密交易限制信息发送至所述服务端的步骤包括：
    若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息和所述权益凭证的零知识证明，并将所述加密交易限制信息和所述零知识证明发送至所述服务端；
    所述服务端将所述加密交易限制信息上传至所述区块链的合约数据表中的步骤包括：
    所述服务端将所述加密交易限制信息和所述零知识证明上传至所述区块链，由所述区块链基于所述零知识证明验证所述权益凭证的兑现记录；
    其中，若验证通过，则所述区块链标记所述权益凭证的兑现记录为已兑现，并将所述加密交易限制信息保存在所述合约数据表中。
  8. 如权利要求4所述的凭证验证方法，其中，所述若检测到基于所述权益凭证发起的兑现请求，则确定所述权益凭证的加密交易限制信息，并将所述加密交易限制信息发送至所述服务端的步骤之前，所述凭证验证方法还包括：
    若检测到基于所述权益凭证发起的购买请求，则将预设的验证密钥发送至所述服务端；
    接收所述服务端基于所述购买请求发送的所述权益凭证对应的全局唯一加密凭证、所述服务端的签名公钥和所述全局唯一加密凭证的第一数字签名，并核实所述区块链的合约数据表中是否存在所述全局唯一加密凭证、所述签名公钥和所述第一数字签名，其中，所述服务端基于所述验证密钥和所述权益凭证对应的服务项目生成所述全局唯一加密凭证，并使用所述签名公钥对所述全局唯一加密凭证进行签名，以得到所述第一数字签名；
    若存在，则确定所述权益凭证购买完成。
  9. 如权利要求8所述的凭证验证方法，其中，所述服务端基于所述验证密钥和所述权益凭证对应的服务项目生成所述全局唯一加密凭证的步骤包括：
    所述服务端在接收到所述验证密钥时，基于所述验证密钥和所述权益凭证对应的服务项目，生成对应的服务承诺；
    所述服务端基于所述服务承诺和所述区块链的服务标识，生成所述全局唯一加密凭证。
  10. 一种凭证验证装置，其中，所述凭证验证装置包括：
    检测模块，用于若检测到基于权益凭证发起的验证请求，则从所述验证请求对应的区块链的合约数据表中，获取所述权益凭证的服务内容和所述权益凭证的兑现记录；
    验证模块，获取所述权益凭证的验证密钥、所述权益凭证的服务项目以及所述权益凭证对应的服务端的签名公钥，并基于所述验证密钥、所述服务项目和所述签名公钥，验证所述服务内容；
    所述验证模块，还用于若所述服务内容验证通过，则获取所述权益凭证的兑现附言，并基于所述兑现附言，验证所述兑现记录；
    确定模块，用于若所述兑现记录验证通过，则确定所述权益凭证有效。
  11. 一种凭证验证设备，其中，所述凭证验证设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的凭证验证程序，所述凭证验证程序被所述处理器执行时实现如权利要求1至9中任一项所述的凭证验证方法的步骤。
  12. 一种计算机可读存储介质，其中，所述计算机可读存储介质上存储有凭证验证程序，所述凭证验证程序被处理器执行时实现如权利要求1至9中任一项所述的凭证验证方法的步骤。
PCT/CN2020/111798 2019-09-06 2020-08-27 凭证验证方法、装置、设备与可读存储介质 WO2021043063A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910851095.0 2019-09-06
CN201910851095.0A CN110555772B (zh) 2019-09-06 2019-09-06 凭证验证方法、装置、设备与可读存储介质

Publications (1)

Publication Number Publication Date
WO2021043063A1 true WO2021043063A1 (zh) 2021-03-11

Family

ID=68739781

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/111798 WO2021043063A1 (zh) 2019-09-06 2020-08-27 凭证验证方法、装置、设备与可读存储介质

Country Status (2)

Country Link
CN (1) CN110555772B (zh)
WO (1) WO2021043063A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113094748A (zh) * 2021-04-20 2021-07-09 西安交通大学 一种基于区块链的可认证匿名电商评价机制的实现方法
CN113746640A (zh) * 2021-09-26 2021-12-03 网易（杭州）网络有限公司 数字凭证使用方法、装置、计算机设备及存储介质
CN113806807A (zh) * 2021-09-22 2021-12-17 合肥工业大学 一种基于隐私合约的网约车系统与方法
CN114124494A (zh) * 2021-11-12 2022-03-01 中国联合网络通信集团有限公司 一种数据处理方法、装置、设备及存储介质

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110555772B (zh) * 2019-09-06 2023-03-21 深圳前海微众银行股份有限公司 凭证验证方法、装置、设备与可读存储介质
CN111339188B (zh) * 2020-02-20 2023-10-31 百度在线网络技术（北京）有限公司 基于区块链的媒介内容处理方法、装置、设备和介质
CN113688356A (zh) * 2020-05-18 2021-11-23 国家广播电视总局广播电视科学研究院 数字媒体内容的权益控制方法、装置、设备及存储介质
CN111738857B (zh) * 2020-06-28 2021-07-06 深圳前海微众银行股份有限公司 应用于区块链的隐匿支付证明的生成与验证方法及装置
CN112116474B (zh) * 2020-09-21 2023-12-05 京东科技信息技术有限公司 电子合同的验证方法、装置、电子设备及存储介质
CN112287040B (zh) * 2020-10-30 2022-11-04 深圳前海微众银行股份有限公司 一种基于区块链的权益合并方法、装置、设备及介质
CN112633890B (zh) * 2020-12-22 2024-04-05 深圳前海微众银行股份有限公司 一种基于区块链的隐匿权益证明的验证方法及装置
CN113139209B (zh) * 2021-04-15 2023-09-26 中国科学院软件研究所 一种基于原子性签名的可验证凭据实现方法和系统
CN112990925B (zh) * 2021-04-21 2021-08-10 支付宝(杭州)信息技术有限公司 资产凭证的管理方法及装置
CN113259094B (zh) * 2021-04-21 2022-03-25 山东大学 一种通用的层级签名加密系统与构建方法
CN116192540B (zh) * 2023-05-05 2023-07-11 敏于行(北京)科技有限公司 动态组合可验证凭证的验证方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170011460A1 (en) * 2015-07-09 2017-01-12 Ouisa, LLC Systems and methods for trading, clearing and settling securities transactions using blockchain technology
US20180144345A1 (en) * 2016-11-23 2018-05-24 Kim Wagner Assurance exchange
CN109446842A (zh) * 2018-10-31 2019-03-08 深圳电通信息技术有限公司 一种基于区块链和分布式账本的版权权益交易方法及装置
CN109951511A (zh) * 2019-01-08 2019-06-28 上海大学 基于区块链平台的买方卖方安全数字水印协议生成方法
CN110555772A (zh) * 2019-09-06 2019-12-10 深圳前海微众银行股份有限公司 凭证验证方法、装置、设备与可读存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8762741B2 (en) * 2009-01-29 2014-06-24 Microsoft Corporation Privacy-preserving communication
PL3073670T4 (pl) * 2015-03-27 2021-08-23 Black Gold Coin, Inc. System i sposób osobistej identyfikacji i weryfikacji
CN108764874B (zh) * 2018-05-17 2021-09-07 深圳前海微众银行股份有限公司 基于区块链的匿名转账方法、系统及存储介质
CN109922077B (zh) * 2019-03-27 2021-06-04 北京思源理想控股集团有限公司 一种基于区块链的身份认证方法及其系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170011460A1 (en) * 2015-07-09 2017-01-12 Ouisa, LLC Systems and methods for trading, clearing and settling securities transactions using blockchain technology
US20180144345A1 (en) * 2016-11-23 2018-05-24 Kim Wagner Assurance exchange
CN109446842A (zh) * 2018-10-31 2019-03-08 深圳电通信息技术有限公司 一种基于区块链和分布式账本的版权权益交易方法及装置
CN109951511A (zh) * 2019-01-08 2019-06-28 上海大学 基于区块链平台的买方卖方安全数字水印协议生成方法
CN110555772A (zh) * 2019-09-06 2019-12-10 深圳前海微众银行股份有限公司 凭证验证方法、装置、设备与可读存储介质

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113094748A (zh) * 2021-04-20 2021-07-09 西安交通大学 一种基于区块链的可认证匿名电商评价机制的实现方法
CN113094748B (zh) * 2021-04-20 2024-01-19 西安交通大学 一种基于区块链的可认证匿名电商评价机制的实现方法
CN113806807A (zh) * 2021-09-22 2021-12-17 合肥工业大学 一种基于隐私合约的网约车系统与方法
CN113806807B (zh) * 2021-09-22 2024-02-13 合肥工业大学 一种基于隐私合约的网约车系统与方法
CN113746640A (zh) * 2021-09-26 2021-12-03 网易（杭州）网络有限公司 数字凭证使用方法、装置、计算机设备及存储介质
CN113746640B (zh) * 2021-09-26 2024-03-01 网易（杭州）网络有限公司 数字凭证使用方法、装置、计算机设备及存储介质
CN114124494A (zh) * 2021-11-12 2022-03-01 中国联合网络通信集团有限公司 一种数据处理方法、装置、设备及存储介质
CN114124494B (zh) * 2021-11-12 2023-06-30 中国联合网络通信集团有限公司 一种数据处理方法、装置、设备及存储介质

Also Published As

Publication number Publication date
CN110555772A (zh) 2019-12-10
CN110555772B (zh) 2023-03-21

Similar Documents

Publication Publication Date Title
WO2021043063A1 (zh) 凭证验证方法、装置、设备与可读存储介质
US10826702B2 (en) Secure authentication of user and mobile device
CN110473105B (zh) 一种区块链交易结算方法、系统及相关设备
US11210661B2 (en) Method for providing payment gateway service using UTXO-based protocol and server using same
EP1397787B1 (en) System and method of bootstrapping a temporary public -key infrastructure from a cellular telecommunication authentication and billing infrastructure
JP4518942B2 (ja) セルラー式電気通信と認可基盤を使った、商品とサービスの安全な認証と請求のシステム及び方法
US8561892B2 (en) System and method for completing a transaction with a payment terminal
US20180150830A1 (en) System, process and device for e-commerce transactions
CN108476227A (zh) 用于设备推送供应的系统和方法
US20110276492A1 (en) Authenticated payment
CN110535648A (zh) 电子凭证生成及验证和密钥控制方法、装置、系统和介质
KR20150106198A (ko) 인증 방법, 인증 중계 서버 및 단말
JP2018529137A (ja) サービス認証のための方法および装置
JP2020046925A (ja) 認証システム
Sung et al. Mobile Payment Based on Transaction Certificate Using Cloud Self‐Proxy Server
KR101581663B1 (ko) 공인인증기관 연동 인증 및 부인 방지 방법 및 시스템
JP2009043012A (ja) 決済システム、店舗装置、決済機関装置および決済方法
JP6874700B2 (ja) 電子商取引システム、通信端末、第三者機関サーバ、電子商取引方法、およびプログラム
TWI841835B (zh) 透過行動裝置控制區域支付終端之支付系統、方法及電腦可讀媒介
Ferrer-Gomila A Selective Privacy-Preserving Identity Attributes Protocol for Electronic Coupons

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: 20859898

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: 20859898

Country of ref document: EP

Kind code of ref document: A1