Blockchain-based identity verification method, apparatus, device, and medium

Abstract

This specification provides a blockchain-based identity verification method, apparatus, device, and medium. The method includes: a first device receiving verification information from a user device held by a first user; the verification information including a zero-knowledge proof; the zero-knowledge proof being used to prove that the first user holds authenticated credential data and that the state data of the blockchain stores first commitment data obtained based on the credential data; the first device sending a first transaction to the blockchain based on the verification information; and the nodes of the blockchain performing verification operations on the zero-knowledge proof according to the first transaction.

Description

Technical Field

[0001] This specification relates to the field of blockchain technology, and in particular to a blockchain-based authentication method, apparatus, device, and medium. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application.

[0003] The rise of decentralized finance (DeFi), Web 3.0, and other blockchain-based applications has spurred the demand for data management via blockchain. Currently, there is a need for a blockchain-based identity verification solution. Summary of the Invention

[0004] This specification provides one or more embodiments of a blockchain-based authentication method, apparatus, device, and medium.

[0005] According to a first aspect, a blockchain-based identity verification method is provided, wherein a first device receives verification information from a user device held by a first user; the verification information includes a zero-knowledge proof; the zero-knowledge proof is used to prove that the first user holds credential data that has passed identity authentication, and that the state data of the blockchain stores first commitment data obtained based on the credential data;

[0006] The first device sends a first transaction to the blockchain based on the verification information;

[0007] The nodes of the blockchain perform verification operations on the zero-knowledge proof based on the first transaction.

[0008] According to a second aspect, a blockchain-based authentication method is provided, the method being executed by nodes in the blockchain; the method includes:

[0009] The system receives a first transaction sent by a first device based on verification information; the verification information is obtained by the first device from a user device held by a first user; the verification information includes a zero-knowledge proof; the zero-knowledge proof is used to prove that the first user holds credential data that has passed identity authentication, and that the state data of the blockchain stores first commitment data obtained based on the credential data;

[0010] Based on the first transaction, a verification operation is performed on the zero-knowledge proof.

[0011] According to a third aspect, a blockchain-based identity verification device is provided, the device being deployed on a node of a blockchain; the device includes:

[0012] A receiving module is configured to receive a first transaction sent by a first device based on verification information; the verification information is obtained by the first device from a user device held by a first user; the verification information includes a zero-knowledge proof; the zero-knowledge proof is used to prove that the first user holds credential data that has passed identity authentication, and that the state data of the blockchain stores first commitment data obtained based on the credential data;

[0013] The verification module is used to perform verification operations on the zero-knowledge proof based on the first transaction.

[0014] According to a fourth aspect, a computer-readable storage medium is provided, the storage medium storing a computer program that, when executed by a processor, implements the method described in any one of the first or second aspects above.

[0015] According to a fifth aspect, a computing device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in any one of the first or second aspects above.

[0016] The technical solutions provided in the embodiments of this specification may include the following beneficial effects:

[0017] The blockchain-based identity verification scheme provided in the embodiments of this specification can verify the user's identity through a blockchain system using zero-knowledge proofs that prove the user holds credential data. This credential data is a verified identity credential used to verify the user's identity. This achieves decentralized management of user privacy data without disclosing the user's personal privacy data, improving the security of user privacy data. Furthermore, it enables the reusability of user identity verification credentials, allowing users to avoid repeating identity verification in different projects.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This specification is an architectural diagram of a blockchain system illustrated according to an exemplary embodiment;

[0021] Figure 2 This specification illustrates a blockchain-based identity verification scenario according to an exemplary embodiment.

[0022] Figure 3 This specification illustrates an interactive flowchart of a blockchain-based identity verification method according to an exemplary embodiment.

[0023] Figure 4A This is a schematic diagram of a Merkle tree illustrated in this specification according to an exemplary embodiment;

[0024] Figure 4B This is a schematic diagram illustrating a verification process for zero-knowledge proof according to an exemplary embodiment of this specification;

[0025] Figure 5 This is a block diagram illustrating a blockchain-based authentication device according to an exemplary embodiment of this specification. Detailed Implementation

[0026] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0027] Figure 1 An architecture diagram of a blockchain system in one embodiment is shown. Figure 1 As shown, the blockchain system includes N nodes. Figure 1The diagram illustrates nodes 1 through 8. The lines connecting the nodes schematically represent connections between them, used for data transfer. These nodes can store the entire ledger, that is, the state of all blocks and all accounts. Each node in the blockchain system can produce the same state within the blockchain system by executing the same transactions, and each node can store the same state database.

[0028] In the blockchain field, a transaction refers to a task unit executed and recorded within the blockchain system. A transaction typically includes a send field (From), a receive field (To), and a data field (Data). Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0029] Blockchain systems offer smart contract functionality. A smart contract on a blockchain is a contract that can be triggered and executed by transactions. Smart contracts can be defined in the form of code. Invoking a smart contract within a blockchain system involves initiating a transaction pointing to the smart contract's address, causing each node in the blockchain system to run the smart contract code in a distributed manner.

[0030] In a contract deployment scenario, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to a server such as... Figure 1 In the blockchain system shown, the `data` field of the transaction includes the code (such as bytecode or machine code) of the contract to be created, and the `to` field of the transaction is empty to indicate that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, they determine the contract address "0x6f8ae93…". Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates state storage corresponding to the contract account, stores the contract code, and saves the hash value of the contract code in the contract's state storage, thus the contract is successfully created.

[0031] In scenarios where contracts are invoked, for example, Bob sends a transaction to invoke a smart contract, such as... Figure 1 In the blockchain system shown, the `from` field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the `to` field is the aforementioned "0x6f8ae93…", which is the address of the smart contract being invoked, and the `data` field of the transaction includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction in the blockchain system, each node in the blockchain system can execute the transaction separately, thereby executing the contract separately, and updating the state database based on the execution of the contract.

[0032] Currently, for some services / products, such as those in the financial sector, users need to verify their identity before using them. Successful identity verification is required to access these services / products. In related technologies, some organizations or institutions providing KYT (Know Your Customer) services can collect user identity information and verify it through biometric technology and data collection. However, this method cannot achieve decentralized management of user privacy data without leaking it.

[0033] Therefore, this specification provides an embodiment based on Figure 1 The blockchain-based identity verification scheme described herein can verify user identity using zero-knowledge proofs that prove a user holds credential data. This credential data is a verified identity credential, thus verifying the user's identity. This achieves decentralized management of user privacy data without disclosing it, improving data security. Furthermore, it enables the reusability of authentication credentials, eliminating the need for users to repeatedly verify their identity in different projects.

[0034] Figure 2 A schematic diagram of a blockchain-based identity verification scenario is shown. For example... Figure 2 As shown, a blockchain-based identity verification system may include a blockchain 201, a user 202, a verifier 203, and an authenticator 204. Verifier 203 and authenticator 204 can both establish communication connections with blockchain 201 through their respective devices. User 202 and verifier 203 can also establish communication connections with each other through their respective devices.

[0035] In this system, User 202 is an individual / organization / institution requiring identity authentication. User 202 can submit their ID information to Authentication Party 204 in advance, which will then verify and authenticate it. If the verification is successful, Authentication Party 204 can use its device to generate authenticated credential data S for User 202 and return credential data S to User 202. Additionally, Authentication Party 204 can use its device to obtain commitment data C based on credential data S. For example, a pre-defined hash calculation can be performed on User 202's address A and credential data S to obtain commitment data C, thus binding User 202 and credential data S. The commitment data C is then uploaded to blockchain 201 for on-chain storage.

[0036] When user 202 uses a service W / product P that requires identity authentication, since the commitment data C corresponding to user 202 is already stored in blockchain 201, user 202 does not need to re-authenticate. They can directly verify their possession of the credential data S corresponding to the commitment data C based on the blockchain. Specifically, user 202 can generate a zero-knowledge proof Q locally using their device. Zero-knowledge proof Q can include parts a and b. Part a proves that user 202 holds the credential data S corresponding to the commitment data C, and that the commitment data C is stored in blockchain 201. Part b proves that user 202 has a binding relationship with the commitment data C. Specifically, since the address A corresponding to user 202 is user 202's private data, part b can include an encrypted address M obtained by encrypting address A based on a salt value H.

[0037] Next, user 202 can send verification information to verifier 203, where verifier 203 can be a trusted intermediary. The verification information may include a zero-knowledge proof Q, the address to be verified A', and the salt value H'. After receiving the verification information, verifier 203 can obtain the encrypted address M' to be verified based on the address A' and the salt value H'. It then compares the encrypted address M included in part b of the zero-knowledge proof Q of the encrypted address M'. If the encrypted address M' matches the encrypted address M, verifier 203 can send a transaction TX including the zero-knowledge proof Q to blockchain 201. It should be noted that if the credential data S is processed based on the address A corresponding to user 202 to generate commitment data C, then sending transaction TX to blockchain 201 through verifier 203 can avoid exposing the address A corresponding to user 202.

[0038] After receiving transaction TX, blockchain 201 executes transaction TX and verifies the zero-knowledge proof Q. Specifically, part a of the zero-knowledge proof Q proves that user 202 holds the credential data S corresponding to the promised data C, and that the promised data C is stored in blockchain 201. Part b of the zero-knowledge proof Q proves that user 202 and the promised data C are bound together. If the verification of the zero-knowledge proof Q is successful, it can be determined that user 202 is a legitimate user who has passed identity authentication, thus allowing user 202 to use service W / product P.

[0039] The solutions provided in this specification will be described in detail below with reference to specific embodiments.

[0040] like Figure 3 As shown, Figure 3This is an interactive flowchart illustrating a blockchain-based authentication method according to an exemplary embodiment. The method involves a first device (e.g., a device held by the authenticator), a user device (e.g., a device held by the user), a second device (e.g., a device held by the authenticator), and blockchain nodes. The first device, user device, second device, and blockchain nodes can all be implemented as any device, platform, server, or device cluster with computing and processing capabilities. The method includes the following steps:

[0041] In step 301, the second device generates credential data for the first user and obtains the first commitment data based on the credential data.

[0042] In this embodiment, firstly, the authenticator verifies the identity of the first user. The authenticator can be an organization or institution capable of providing KYT services. After the authenticator confirms successful authentication of the first user, it can generate credential data for the first user through its second device. This credential data is unique and unpredictable; therefore, it can be, for example, a randomly generated random number.

[0043] Next, on one hand, the second device can return the credential data to the first user. On the other hand, the second device can obtain first commitment data based on the credential data. This first commitment data can be determined, for example, by performing a preset hash calculation on the first identifier corresponding to the first user and the credential data, thereby binding the credential data to the first user. The first identifier can be a unique identifier corresponding to the first user, such as the blockchain account address corresponding to the first user. Since both the first identifier and the credential data are unique, the first commitment data obtained through the preset hash calculation based on the first identifier and the credential data is also unique (i.e., different users correspond to different commitment data).

[0044] In step 303, the second device instructs the blockchain nodes to upload the first commitment data to the blockchain for verification.

[0045] In this embodiment, after generating the first commitment data, the second device can send a second transaction to the blockchain to invoke the target contract. The second transaction includes the first commitment data. The state data of the contract account corresponding to the target contract in the blockchain stores a Merkle tree constructed from the commitment data of multiple users. Each leaf node in the Merkle tree corresponds to a user, and any leaf node can store the commitment data of one user. It should be noted that the aforementioned Merkle tree constructed from the commitment data is public data, and all users can obtain the Merkle tree or query the data within it.

[0046] After receiving the second transaction, the blockchain node executes it. By running the target contract, it updates the Merkle tree using the first commitment data for on-chain notarization. Specifically, a new leaf node can be created in the Merkle tree, the first commitment data can be stored in the new leaf node, and the parent node and root node of the new leaf node in the Merkle tree can be updated. Figure 4A A schematic diagram of a Merkel tree, as shown below. Figure 4A As shown, leaf nodes 1, 2, 3, and 4 correspond to the commitment data of four different users. For example, leaf node 1 stores the commitment data for user 1, leaf node 2 stores the commitment data for user 2, leaf node 3 stores the commitment data for user 3, and leaf node 4 stores the commitment data for user 4. Node 5 stores the hash value obtained by hashing nodes 1 and 2, and node 6 stores the hash value obtained by hashing nodes 3 and 4. Node 7 is the root node of this Merkle tree and stores the hash value obtained by hashing nodes 5 and 6.

[0047] In step 305, the user equipment sends verification information to the first device.

[0048] In this embodiment, when the first user needs to prove that they have passed identity authentication, they can obtain verification information through their user device. Specifically, firstly, the user device can obtain the credential data held by the first user, which may be the credential data returned to the user device by the second device in step 301. Next, the user device can generate a zero-knowledge proof based on the credential data. This zero-knowledge proof can be used to prove that the first user holds credential data that has passed identity authentication, and that the state data of the blockchain stores first commitment data obtained based on this credential data. After generating the zero-knowledge proof, the user device can obtain verification information, which includes the zero-knowledge proof, a preset salt value, and a first identifier. The user device can then send the verification information to the first device.

[0049] Specifically, the user equipment (UE) can generate zero-knowledge proofs as follows: The UE obtains the blockchain account address corresponding to the first user as the first identifier. It then obtains the path corresponding to the first commitment data in the Merkle tree. For example, the UE can directly, or through other devices, obtain the Merkle tree currently constructed based on the commitment data from the blockchain, and then perform a hash calculation based on the first identifier and credential data to obtain the first commitment data. Next, it finds the leaf node corresponding to the first commitment data in the Merkle tree and obtains the path corresponding to the first commitment data in the Merkle tree based on this leaf node. Simultaneously, based on this path and the aforementioned Merkle tree, it obtains reference data for calculating the root of the Merkle tree.

[0050] refer to Figure 4ATaking the first commitment data stored at node 2 as an example, the path corresponding to the first commitment data in the Merkle tree can include nodes 2, 5, and 7. However, to calculate the root of the Merkle tree based on the first commitment data, the data corresponding to nodes 1 and 6 are also needed. Therefore, the data stored at nodes 1 and 6 can be used as reference data.

[0051] Next, a preset salt value for encryption can be obtained. Based on this preset salt value, a preset encryption algorithm can be used to encrypt the first identifier, resulting in an encrypted identifier. Furthermore, based on the first commitment data, the path corresponding to the first commitment data in the Merkle tree, and reference data, the root of the Merkle tree is calculated. Using a preset algorithm (e.g., a zero-knowledge proof circuit algorithm), a zero-knowledge proof is generated based on the aforementioned preset salt value, the first identifier, the credential data, the path corresponding to the first commitment data in the Merkle tree, and the reference data. The generated zero-knowledge proof can include an input part for the input circuit algorithm. The input part can include hidden data and public data. The hidden data can include the salt-encrypted ciphertext, the first identifier ciphertext, the credential data ciphertext, the path corresponding to the first commitment data in the Merkle tree ciphertext, and the reference data ciphertext after encryption processing. The public data can include the encrypted identifier and the root of the Merkle tree.

[0052] When verifying zero-knowledge proofs, the hidden data and public data included in the input part can be fed into the circuit algorithm, which then outputs the verification result. If the verification result indicates successful verification, it means that based on the salt ciphertext and the first identifier ciphertext included in the hidden data, the encrypted identifier included in the public data can be obtained. Furthermore, based on the first identifier ciphertext, the credential data ciphertext, the path ciphertext corresponding to the first commitment data in the Merkle tree, and the reference data ciphertext included in the hidden data, the root of the Merkle tree included in the public data can be obtained, thus verifying the authenticity and validity of the credential data.

[0053] In step 307, the first device sends the first transaction to the blockchain based on the verification information.

[0054] In this embodiment, the first device can first obtain a preset salt value and a first identifier from the verification information, and perform a preset hashing process on the first identifier based on the preset salt value to generate an encrypted identifier to be verified. Then, the first device can compare the encrypted identifier to be verified with the encrypted identifier included in the public data of the zero-knowledge proof. If the two match, the first device can send a first transaction to the blockchain based on the zero-knowledge proof included in the verification information. The first transaction includes the aforementioned zero-knowledge proof and calls the target contract that stores the aforementioned Merkle tree.

[0055] In step 309, the blockchain nodes perform verification operations for zero-knowledge proofs based on the first transaction.

[0056] In this embodiment, after receiving the first transaction, the blockchain node executes the first transaction to run the target contract and verify the zero-knowledge proof. Specifically, the blockchain node can obtain the root of the Merkle tree from the contract state corresponding to the target contract and compare it with the root of the Merkle tree included in the publicly available data of the zero-knowledge proof. If they match, the input part of the zero-knowledge proof can be further obtained, and the input part can be fed into the circuit algorithm. The circuit algorithm outputs the verification result, and the blockchain node can store the verification result on the blockchain and return it to the user device. The circuit algorithm can be pre-deployed in the target contract.

[0057] Figure 4B A schematic diagram of the verification process for zero-knowledge proofs, such as... Figure 4B As shown, the hidden inputs in zero-knowledge proof, including the salt value ciphertext, the first identifier ciphertext, the credential data ciphertext, the path ciphertext of the first commitment data in the Merkle tree, and the reference data ciphertext, can be input into the circuit algorithm, and the circuit algorithm can output the verification result, such as true (indicating that the verification passed) or false (indicating that the verification failed).

[0058] The blockchain-based identity verification method provided in the embodiments described above can verify the user's identity through a blockchain system using zero-knowledge proofs that prove the user holds credential data. This credential data is a verified identity credential. This achieves decentralized management of user privacy data without disclosing the user's personal privacy data, improving the security of user privacy data. Furthermore, it enables the reusability of user identity verification credentials, eliminating the need for users to repeatedly verify their identity in different projects.

[0059] It should be noted that although the operations of the methods of the embodiments of this specification are described in a specific order in the above embodiments, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowcharts may be executed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0060] Corresponding to the aforementioned embodiments of blockchain-based authentication methods, this specification also provides embodiments of blockchain-based authentication devices.

[0061] like Figure 5 As shown, Figure 5This specification illustrates a block diagram of a blockchain-based authentication device according to an exemplary embodiment. The device is deployed on a blockchain node and may include a receiving module 501 and an authentication module 502.

[0062] The receiving module 501 is used to receive the first transaction sent by the first device based on the verification information. The verification information is obtained by the first device from the user device held by the first user. The verification information includes a zero-knowledge proof. The zero-knowledge proof is used to prove that the first user holds credential data that has passed identity authentication and that the state data of the blockchain stores the first commitment data obtained based on the credential data.

[0063] Verification module 502 is used to perform verification operations on zero-knowledge proofs based on the first transaction.

[0064] In some implementations, the state data of the blockchain stores a Merkle tree based on the commitment data of multiple users, wherein the commitment data of any user corresponds to a leaf node of the Merkle tree.

[0065] In other implementations, the first commitment data is determined by a preset hash calculation of the first identifier and credential data corresponding to the first user.

[0066] In other implementations, zero-knowledge proofs are generated as follows: obtaining the blockchain account address corresponding to the first user as the first identifier, obtaining the path of the first commitment data in the Merkle tree and the reference data used to calculate the root of the Merkle tree, and generating a zero-knowledge proof based on the credential data, the first identifier, the path and the reference data.

[0067] In other implementations, a zero-knowledge proof is generated based on the credential data, the first identifier, the path, and the reference data in the following manner: a preset salt value is obtained for generating an encrypted identifier for the first identifier; a zero-knowledge proof is generated based on the preset salt value, the credential data, the first identifier, the path, and the reference data, such that the public data of the zero-knowledge proof includes the encrypted identifier and the Merkle root corresponding to the first commitment data.

[0068] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of one or more embodiments of this specification, depending on actual needs. Those skilled in the art can understand and implement this without creative effort.

[0069] This specification also provides one or more embodiments of a computer-readable storage medium storing a computer program that can be used to perform the above-described actions. Figure 3 The blockchain-based authentication method provided in any embodiment.

[0070] One or more embodiments of this specification also provide a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the above-described... Figure 3 The blockchain-based authentication method provided in any embodiment.

[0071] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0072] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0073] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0074] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0075] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0076] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0077] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0078] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0079] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0080] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0081] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0082] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0083] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0084] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0085] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A blockchain-based authentication method, the method comprising: The first device receives verification information from the user equipment held by the first user; The verification information includes zero-knowledge proofs; The zero-knowledge proof is used to prove that the first user holds credential data that has been authenticated and that the state data of the blockchain stores first commitment data based on the credential data. The first device sends a first transaction to the blockchain based on the verification information; The nodes of the blockchain perform verification operations on the zero-knowledge proof based on the first transaction.

2. The method according to claim 1, wherein, The state data of the blockchain stores a Merkle tree based on the commitment data of multiple users, wherein the commitment data of any user corresponds to a leaf node of the Merkle tree.

3. The method according to claim 1, wherein, The first commitment data is determined by performing a preset hash calculation on the first identifier corresponding to the first user and the credential data.

4. The method according to claim 1, wherein, Before the first device receives the verification information, the second device performs the following operations: After confirming that the first user's identity has been successfully authenticated, credential data for the first user is generated. Based on the credential data, the first commitment data is obtained and then stored on the blockchain for verification.

5. The method according to claim 2, wherein, Before the first device receives the verification information, the user equipment performs the following operations: Obtain the voucher data; Based on the aforementioned credential data, a zero-knowledge proof is generated; Based on the zero-knowledge proof, the verification information is sent to the first device.

6. The method according to claim 5, wherein, The generation of zero-knowledge proofs based on the credential data includes: Obtain the blockchain account address corresponding to the first user as the first identifier; Obtain the path corresponding to the first commitment data in the Merkle tree and the reference data used to calculate the root of the Merkle tree; A zero-knowledge proof is generated based on the credential data, the first identifier, the path, and the reference data.

7. The method according to claim 6, wherein, The process of generating a zero-knowledge proof based on the credential data, the first identifier, the path, and the reference data includes: Obtain a preset salt value for generating an encrypted identifier for the first identifier; Based on the preset salt value, the credential data, the first identifier, the path, and the reference data, a zero-knowledge proof is generated, such that the public data of the zero-knowledge proof includes the encrypted identifier and the Merkle root corresponding to the first commitment data.

8. The method according to claim 7, wherein, The verification information also includes the preset salt value and the first identifier; wherein, sending the first transaction to the blockchain based on the verification information includes: Based on the preset salt value and the first identifier, an encrypted identifier to be verified is generated; If the encrypted identifier to be verified is consistent with the encrypted identifier included in the public data of the zero-knowledge proof, then a first transaction is sent to the blockchain based on the zero-knowledge proof included in the verification information.

9. A blockchain-based authentication method, the method being executed by nodes of the blockchain; the method comprising: Receive the first transaction sent by the first device based on verification information; The verification information is obtained by the first device from the user device held by the first user; The verification information includes zero-knowledge proofs; the zero-knowledge proofs are used to prove that the first user holds credential data that has passed identity authentication, and that the state data of the blockchain stores first commitment data obtained based on the credential data; Based on the first transaction, a verification operation is performed on the zero-knowledge proof.

10. The method according to claim 9, wherein, The state data of the blockchain stores a Merkle tree based on the commitment data of multiple users, wherein the commitment data of any user corresponds to a leaf node of the Merkle tree.

11. The method according to claim 9, wherein, The first commitment data is determined by performing a preset hash calculation on the first identifier corresponding to the first user and the credential data.

12. The method according to claim 10, wherein, The zero-knowledge proof is generated in the following manner: Obtain the blockchain account address corresponding to the first user as the first identifier; Obtain the path corresponding to the first commitment data in the Merkle tree and the reference data used to calculate the root of the Merkle tree; A zero-knowledge proof is generated based on the credential data, the first identifier, the path, and the reference data.

13. The method according to claim 12, wherein, The process of generating a zero-knowledge proof based on the credential data, the first identifier, the path, and the reference data includes: Obtain a preset salt value for generating an encrypted identifier for the first identifier; Based on the preset salt value, the credential data, the first identifier, the path, and the reference data, a zero-knowledge proof is generated, such that the public data of the zero-knowledge proof includes the encrypted identifier and the Merkle root corresponding to the first commitment data.

14. A blockchain-based authentication device, the device being deployed on a node of a blockchain; the device comprising: The receiving module is used to receive the first transaction sent by the first device based on the verification information; The verification information is obtained by the first device from the user device held by the first user; the verification information includes zero-knowledge proof; the zero-knowledge proof is used to prove that the first user holds credential data that has passed identity authentication, and that the state data of the blockchain stores first commitment data obtained based on the credential data; The verification module is used to perform verification operations on the zero-knowledge proof based on the first transaction.

15. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-13.

16. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-13.

Images