Method for carrying out identity authentication on account in block chain system

Abstract

A method for performing identity authentication on an account in a block chain system comprises the steps of obtaining a first transaction comprising a zero knowledge proof and a first root hash, a public input of the zero knowledge proof comprising a first account address, an authentication item public key subset and a first signature, the zero-knowledge proof is used for proving that the first root hash is calculated based on first secret data input by a first user, the first signature is an aggregate signature of sub-signatures corresponding to an authentication item public key subset, and each sub-signature is generated by signing a first certificate of the first user by an identity authentication mechanism; the authentication item public key corresponds to an identity authentication item. Under the condition that the zero-knowledge proof passes verification and the first root hash is the same as a second root hash stored in the block chain system, the first signature is verified, and the second root hash is uploaded by an identity authentication mechanism and is a root hash of an authentication Merck tree; and under the condition that the verification is passed, determining the passed identity authentication item of the first account address according to the authentication item public key subset.

Description

Technical Field

[0001] This specification relates to the field of blockchain technology, and more particularly to a method for authenticating accounts in a blockchain system. 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] For example, in one blockchain technology practice, decentralized finance (DeFi) allows users to exchange and transfer various financial assets through blockchain accounts, greatly improving the efficiency and transparency of financial transactions. However, with the increasing sophistication of blockchain infrastructure and the maturity and widespread adoption of smart contract technology, decentralized finance has developed rapidly, and the transfer of financial assets on the blockchain is facing increasingly severe compliance challenges. Financial regulatory agencies typically require various financial activities to comply with relevant regulations, such as anti-money laundering (AML) and combating the financing of terrorism (CFT), etc. Their core requirement is to require financial service providers to verify the identity of account holders participating in financial activities (Know Your Customer, KYC).

[0004] Beyond the DeFi scenarios exemplified above, other practical applications of blockchain also require identity verification for accounts within the blockchain system. Therefore, there is a desired technical solution that can verify the identity of accounts within the blockchain system while maintaining its decentralized and transparent nature and without disclosing any user privacy information, while simultaneously disclosing the identity verification information obtained by the user. Summary of the Invention

[0005] This specification provides a first aspect of a method for authenticating accounts in a blockchain system, executed by nodes of the blockchain system, comprising:

[0006] The first transaction is obtained, which calls the verification contract and contains first proof data. The first proof data includes at least a zero-knowledge proof and a first root hash. The zero-knowledge proof is used to prove that the first root hash is calculated based on the first secret data input by the first user. The public input of the zero-knowledge proof includes a first account address, a subset of authentication item public keys, and a first signature. The first signature is an aggregate signature of the sub-signatures corresponding to each authentication item public key in the subset of authentication item public keys. Each of the sub-signatures is generated by the identity authentication authority signing the first credential corresponding to the first user. The authentication item public key corresponds to the identity authentication item of the identity authentication authority.

[0007] Based on the first transaction, the verification contract is invoked to perform the following steps: verify the zero-knowledge proof based on the first root hash; if the zero-knowledge proof verification passes, determine whether the first root hash is the same as the second root hash stored in the blockchain system, the second root hash being uploaded by the identity authentication authority and being the root hash of the authentication Merk tree, the authentication Merk tree being constructed by the identity authentication authority based on the hash values ​​of the secret data of multiple users who have passed identity authentication; if the first root hash and the second root hash are the same, verify the first signature based on the subset of the authentication item public key; if the first signature verification passes, determine the first account address has passed the identity authentication item based on the subset of the authentication item public key.

[0008] The second aspect of this specification provides a method for authenticating accounts in a blockchain system, performed by an authentication authority, including:

[0009] Receive the secret hash corresponding to the secret data sent by the first user, as well as the authentication data.

[0010] Based on the authentication data, identity authentication is performed on the first user, and when the identity authentication is successful, the secret hash is added to the authentication Merk tree. The identity authentication includes several identity authentication items.

[0011] Update the certified Merck tree to obtain the root hash corresponding to the root node of the certified Merck tree, and store the root hash in the blockchain system.

[0012] For any first identity authentication item that has passed, use its corresponding authentication item private key to sign the first credential corresponding to the first user and generate a sub-signature corresponding to the first identity authentication item.

[0013] The sub-signature corresponding to each of the passed identity authentication items, and the Merk path corresponding to the secret hash in the authentication Merk tree, are sent to the first user.

[0014] A third aspect of this specification provides a method for authenticating an account in a blockchain system, executed by a first user's user device, the method comprising:

[0015] First data provided by a first user is input into a first circuit. The first circuit is constructed based on a zero-knowledge proof framework. The first data includes at least a first Merkle path and first secret data as privacy inputs, a first account address, a subset of authentication item public keys, and a first signature as public inputs. The first signature is an aggregate signature of the sub-signatures corresponding to each authentication item public key in the subset of authentication item public keys. Each of the sub-signatures is generated by signing the first credential corresponding to the first user by an identity authentication authority. The authentication item public key corresponds to the identity authentication item of the identity authentication authority.

[0016] The first circuit performs the following steps: hashing the first secret data to obtain a secret hash; using the secret hash as a leaf node, calculating the first root hash based on the first Merk path; generating a zero-knowledge proof, which includes the first account address, a subset of the authentication item public key, and a first signature, wherein the zero-knowledge proof is used to prove that the first root hash is calculated based on the first secret data.

[0017] A first transaction is sent to the blockchain system. The first transaction invokes a verification contract and includes first proof data, which includes at least the zero-knowledge proof and a first root hash. The verification contract is used to verify the zero-knowledge proof. If the zero-knowledge proof is verified successfully, it determines whether the first root hash is the same as a second root hash stored in the blockchain system. The second root hash is uploaded by the identity authentication authority and is the root hash of the authentication Merk tree. The authentication Merk tree is constructed by the identity authentication authority based on the hash values ​​of the secret data of multiple authenticated users. If the first root hash and the second root hash are the same, a first signature is verified based on a subset of the authentication item's public key.

[0018] A fourth aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores a computer program, and the processor, when executing the computer program, implements the methods described in the first, second, or third aspects.

[0019] The method provided in the embodiments of this specification can complete account authentication in a blockchain system without disclosing any user privacy. By employing zero-knowledge proof technology, the user's authenticated information is transformed into a verifiable cryptographic proof. Simultaneously, an aggregate signature is embedded in the proof data. This aggregate signature is formed by aggregating the sub-signatures of the user's authenticated items and corresponds to the public key of the authenticated items. Therefore, without exposing any personal privacy, it is possible not only to prove the successful authentication of the user associated with the blockchain account but also to disclose the authenticated items that the user has authenticated, thus balancing the verifiability of the authenticated content with the protection of user privacy. Attached Figure Description

[0020] 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.

[0021] Figure 1 This is a diagram of the blockchain architecture used in the embodiments of this specification;

[0022] Figure 2 This is a schematic diagram of a typical transfer process in the blockchain system disclosed in this specification;

[0023] Figure 3 This document provides an implementation framework for a method of authenticating accounts in a blockchain system, based on embodiments thereof.

[0024] Figure 4 This is a timing diagram of a method for authenticating accounts in a blockchain system according to embodiments of this specification.

[0025] Figure 5 This is a timing diagram of a method for authenticating accounts in a blockchain system according to embodiments of this specification.

[0026] Figure 6 This is a timing diagram of a method for authenticating accounts in a blockchain system according to embodiments of this specification.

[0027] Figure 7 This is a flowchart illustrating account authentication in an exemplary transfer transaction provided by an embodiment of this specification. Detailed Implementation

[0028] 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.

[0029] Blockchains are generally classified into three types: public blockchains, private blockchains, and consortium blockchains. In addition, there are various combinations of these types, such as private blockchain + consortium blockchain, consortium blockchain + public blockchain, etc. Public blockchains offer the highest degree of decentralization. Participants in a public blockchain can read data records on the chain, participate in transactions, and compete for the right to record new blocks. Furthermore, participants (represented by nodes on the blockchain) can freely join and leave the network and perform related operations. Private blockchains, on the other hand, have write permissions controlled by a specific organization or institution, and data read permissions are regulated by that organization. Simply put, a private blockchain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for internal use within specific institutions. Consortium blockchains fall between public and private blockchains, achieving "partial decentralization." Each node in a consortium blockchain typically has a corresponding entity or organization; participants join the network through authorization and form a consortium of interested parties to jointly maintain the operation of the blockchain.

[0030] Public, private, and consortium blockchains can all provide smart contract functionality. A smart contract on a blockchain is a contract that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code.

[0031] Taking a blockchain system as an example, it allows users to create and invoke complex logic. The core of a programmable blockchain system is a virtual machine (VM), which each blockchain node can run. The VM is a Turing-complete virtual machine, meaning that various complex logics can be implemented using it. Users publish and invoke smart contracts within the blockchain system, which run on the VM. In fact, the virtual machine directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). Smart contracts deployed on the blockchain can be in the form of bytecode.

[0032] like Figure 1 The diagram shown is a blockchain architecture diagram used in the embodiments of this specification.

[0033] Figure 1 In a blockchain, for example, there are eight nodes, numbered 1 to 8. Each node can be implemented as any device, server, or cluster of devices with computing and processing capabilities. These nodes store the complete ledger, containing the state of all blocks and all accounts. Each node in the blockchain generates the same state by executing the same transactions, and each node stores the same state database. Each node is responsible for receiving transactions from clients and initiating consensus proposals to other nodes. These proposals include, for example, information such as multiple transactions in the block to be formed (e.g., block H1) and the submission order of these transactions. After the nodes in the blockchain successfully reach a consensus on the proposal, each node executes these transactions according to the submission order in the proposal, thereby generating block H1.

[0034] Understandable. Figure 1 The blockchain shown is merely exemplary, and the embodiments described in this specification are not limited to applications. Figure 1 The blockchain shown. Additionally... Figure 1 Although the example shows blockchain 101 with 8 nodes, this specification's embodiments are not limited to this and may include other numbers of nodes. Specifically, the nodes included in the blockchain can meet the Byzantine Fault Tolerance (BFT) requirement. The Byzantine Fault Tolerance requirement can be understood as the existence of Byzantine nodes within the blockchain, while the blockchain does not exhibit Byzantine behavior externally. Generally, some Byzantine Fault Tolerance algorithms require a number of nodes greater than 3f+1, where f is the number of Byzantine nodes, such as the Practical Byzantine Fault Tolerance (PBFT) algorithm.

[0035] In the blockchain field, a transaction refers to a task unit executed and recorded within the blockchain. A transaction typically includes a From field, a To field, a Value field, and a Data field. Specifically, in the case of a transaction involving the transfer of native financial assets, the From field represents the account address initiating the transfer (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transfer, the Value field specifies the transfer amount (i.e., the quantity of native financial assets transferred), and the Data field can store additional explanatory information (e.g., transfer notes) as needed, or it can be left blank. In transactions involving the transfer of non-native financial assets, this is typically achieved by calling the smart contract corresponding to the non-native financial asset in the blockchain. In this case, the From field of the transaction represents the account address that initiates the transfer transaction, the To field represents the account address of the smart contract called by the transaction, the Value field can be left blank, and the Data field includes the function name in the called smart contract and the data passed to the function (e.g., the transfer amount, the account address receiving the transfer, etc.), which is used to retrieve the code of the function from the blockchain and execute it when the transaction is executed.

[0036] Blockchain provides the functionality of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed by transactions within the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract on the blockchain involves initiating a transaction pointing to the smart contract's address, causing the smart contract code to run distributedly across each node in the blockchain. It's worth noting that besides users creating smart contracts, the system can also set smart contracts in the genesis block. These contracts are generally called genesis contracts. Typically, genesis contracts can set some blockchain data structures, parameters, attributes, and methods. Furthermore, accounts with system administrator privileges can create or modify system-level contracts (referred to as system contracts). These system contracts can be used to add data structures for different business operations to the blockchain.

[0037] In various blockchain networks that have introduced smart contracts, Ethereum, for example, typically allows accounts to include two types:

[0038] Contract account: Stores the executed smart contract code and the values ​​of the state within the smart contract code; it can typically only be activated by an external account.

[0039] Externally owned account: A user's account, such as an Ethereum owner's account.

[0040] The design of external and contract accounts is essentially a mapping from account addresses to account states. Account states typically include fields such as Nonce, Balance, Storage Root, and CodeHash. Nonce and Balance exist in both external and contract accounts. CodeHash and Storage Root attributes are generally only valid for contract accounts.

[0041] Nonce: A counter. For external accounts, this number can represent the number of transactions sent from the account address; for contract accounts, it can be the number of contracts created by the account.

[0042] Balance: The amount of Ether held by this address.

[0043] Storage Root: The hash of the root node of an MPT tree that organizes the storage of state variables for contract accounts.

[0044] CodeHash: The hash value of the smart contract code. For contract accounts, this is the hash value of the smart contract; for external accounts, since the smart contract is not included, the CodeHash field can generally be an empty string or a string of all zeros.

[0045] MPT stands for Merkle Patricia Tree, a tree structure that combines the features of a Merkle Tree and a Patricia Tree (a compressed prefix tree, a more space-efficient Trie tree, also known as a dictionary tree). The Merkle Tree algorithm calculates a hash value for each transaction, then joins each pair of transactions and calculates the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, such as a 16-ary tree structure, which is often simply referred to as an MPT tree.

[0046] The Ethereum MPT tree data structure includes a state trie. The state trie contains key-value pairs (kv) representing the storage content for each account in the Ethereum network. The "key" in the state trie can be a 160-bit identifier (such as the address of an Ethereum account or part of its hash value, hereinafter referred to as the account address), distributed across storage from the root node to the leaf nodes of the state trie. The "values" in the state trie are generated by encoding the information of the Ethereum account (using Recursive-Length Prefix encoding (RLP)). As mentioned earlier, for external accounts, the values ​​include Nonce and Balance; for contract accounts, the values ​​include Nonce, Balance, CodeHash, and Storage Root.

[0047] A contract account is used to store the state of a smart contract. Once a smart contract is deployed on the blockchain, a corresponding contract account is created. This contract account typically has several states defined by state variables within the smart contract, which generate new values ​​during the smart contract's creation and execution. A smart contract generally refers to a contract defined in code within a blockchain environment that can automatically execute its terms. Once an event triggers a term in the contract (meeting the execution conditions), the code can execute automatically. In the blockchain, the contract's state is stored in a Storage Trie. The hash value of the Storage Trie's root node is stored in the Storage Root, thus locking all the contract's states to that contract account via hash. The Storage Trie is also an MPT tree structure that stores a key-value mapping from state addresses to state values. Information from the root node to the leaf nodes of the Storage Trie tree is arranged sequentially to store the address of a state, while the leaf node stores the state's value.

[0048] 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 1In the blockchain 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, indicating that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93…" is determined. 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, and saves the contract code in the contract's state storage, thus the contract is successfully created.

[0049] In scenarios where contracts are invoked, for example, Bob sends a transaction to invoke a smart contract, such as... Figure 1 In the blockchain shown, the `from` field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the `to` field "0x6f8ae93…" represents 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, each node in the blockchain can execute the transaction, thereby executing the contract separately, and updating the state database based on the execution of the contract.

[0050] Currently, due to its decentralized and immutable characteristics, blockchain is widely used in various fields. Much important data can be stored on the blockchain or used for evidence preservation, which not only prevents data tampering but also facilitates data traceability.

[0051] Leveraging the immutability of blockchain and the automatic execution capabilities of smart contracts, blockchain technology can enable the segmentation, trading, management, and exchange of financial assets. In practice, technologies such as RealWorld Assets Tokenization (RWA) can be used to convert assets (including physical assets such as real estate, production equipment, energy, and gold; equity assets such as stocks, bonds, and funds; and data assets such as data products and source data) into tradable financial assets on the blockchain.

[0052] Taking the execution of financial asset transfers in a blockchain as an example, Figure 2 A typical money transfer process is shown in the attached diagram. Figure 2 As shown, there are accounts corresponding to users on the blockchain. Account A (the transferring account) contains N units of user A's financial assets, in the attached... Figure 2 In the given example, N = 6; User A needs to transfer M units of financial assets (i.e., the portion circled in the dashed box) from Account A to Account B (the receiving account). (See attached...) Figure 2In the given example, M = 4. User A can initiate a transfer transaction using account A, declaring information such as the target account (the on-chain account address of account B), the amount to be transferred, and digitally signing the transaction. This transaction is then broadcast to nodes in the blockchain network. Upon receiving the transaction, the blockchain nodes verify the validity of the digital signature, the continuity of the nonce, and the adequacy of the account balance. If the verification passes, the transaction is added to the transaction pool. After the blockchain nodes package the transaction from the transaction pool and combine it with other transactions to form a new block, they reach a consensus through a preset consensus algorithm and execute the transactions in the new block, thereby deducting the corresponding amount of financial assets from account A and adding them to account B.

[0053] As is well known to those skilled in the art, blockchain accounts are typically identified by account addresses. Each account address uniquely identifies an account; for example, account address 0x123 represents account A, and account address 0x456 represents account B. When a transaction is executed on the blockchain, anyone can query the transaction hash (TxHash) to find information such as the addresses of the initiating / receiving accounts (From / To), the amount transferred, and the transaction status. Although the transaction information is completely public and verifiable, because an on-chain account address is essentially a hash value without explicit semantics, the publicly available transaction information can only indicate that "0x123 transferred 4 units of financial assets to 0x456," but it is impossible to deduce the true user identity behind the account address.

[0054] It should be noted that, in the appendix Figure 2 For the sake of brevity, only one corresponding blockchain account is shown for each user. However, it should be understood that in practical applications, users can have multiple accounts on the blockchain, or even use one-time accounts to enhance privacy.

[0055] It should also be noted that while the "transactions" described in the various embodiments of this specification are mostly illustrated using the transfer of financial assets as an example, their scope of application is not limited to this. In practical applications, the technical solutions proposed in the various embodiments of this specification can be applied to any on-chain operation that requires compliance verification. Specifically, the term "transaction" broadly refers to a data unit created by a user through a blockchain node and ultimately recorded in the blockchain distributed ledger. In the context of blockchain, a transaction can be understood in both a narrow and a broad sense. From a narrow perspective, a transaction usually refers to a financial asset transfer operation initiated by a user, such as completing a transfer between accounts in a blockchain network. From a broad perspective, a transaction can encompass any data record submitted by a user to the blockchain, manifested as various service instructions initiated by the user in a specific domain. Furthermore, in an account model blockchain, a transaction can also refer to data operations used to update account status (such as balance changes).

[0056] In the blockchain transfer transaction example described above, the financial asset can be a stablecoin. Stablecoins are typically issued by issuers on a blockchain system and are value-pegged to fiat currencies by using fiat currency or high-quality liquid assets as collateral. Users can purchase stablecoins for storage, transfer, or participation in other on-chain transactions. In the stablecoin scenario, on-chain assets all originate from compliant channels that provide fiat currency exchange services. Specifically, the stablecoins initially obtained by an on-chain account are either acquired through subscription to a regulated issuer or through exchange with regulated entities such as licensed exchanges and custodians. Due to the stringent regulatory nature of stablecoins, these entities providing stablecoin issuance (issuers, licensed exchanges, custodians, etc.) have verified the true identity of the stablecoin buyers before issuing the coins, ensuring that the initial circulation source of each stablecoin has a compliant identity background and fundamentally eliminating the possibility of anonymous assets being injected onto the chain. Therefore, in the subsequent circulation of stablecoins, it is only necessary to verify the identity of the real user in the receiving account to form a complete compliance chain for the circulation of stablecoins, ensuring that stablecoins have compliance throughout their entire life cycle, effectively avoiding financial risks such as money laundering and terrorist financing, and meeting financial regulatory requirements.

[0057] In the financial sector, the real user identity verification process mentioned above (hereinafter also referred to as identity authentication) is usually called KYC (Know Your Customer). It aims to confirm the authenticity and legality of a user's identity by collecting and verifying the user's identity information (such as a natural person's ID card, a company's business license, etc.) and proof of the source of funds.

[0058] In some related technologies, there have been attempts to introduce KYC (Know Your Customer) processes into blockchain, relying on a single centralized certification authority to maintain a whitelist of blockchain accounts, allowing only account addresses that have passed identity verification to receive on-chain financial assets. However, this type of solution, which implements KYC through a centralized whitelist mechanism, violates the decentralized principle of blockchain and struggles to balance compliance control and user experience. Specifically: First, the association between on-chain account addresses and real user identities is entirely maintained independently off-chain by the centralized certification authority, posing a potential single point of failure and data tampering risk. Second, the whitelist of on-chain account addresses for users who have completed KYC with the centralized certification authority can only be published and maintained on-chain by that centralized certification authority, violating the decentralized principle of blockchain and making whitelist updates public on-chain, making it easy for malicious third parties to track and deduce the association between account address behavior and identity. Third, when users need to change or add on-chain account addresses, they have to re-verify their identity through the centralized certification authority to add the new account address to the whitelist, which undoubtedly increases the cost for users to manage their on-chain accounts and affects user experience. Furthermore, the lack of a streamlined integration between the execution of transfer transactions and account identity verification in existing technologies leads to a disconnect between the two. Therefore, if the receiving account has not completed KYC verification beforehand when a transfer transaction is initiated, the transaction will fail. In other words, from the perspective of the sending account, due to the mandatory KYC verification requirements imposed by regulators, the sending account must know the KYC status of the receiving account in advance in order for the transfer transaction to be executed smoothly, which increases the complexity of user operations for the sending account in the transfer transaction.

[0059] In other related technologies, a combination of decentralized identifiers (DIDs) and verifiable credentials (VCs) is used to introduce KYC capabilities into the blockchain system. Users first complete identity verification at an identity verification authority and receive a digital credential issued in VC form, containing proof of their identity and cryptographically signed. This digital credential is stored by the user in their DID wallet and associated with their DID identifier. When a user needs to conduct a blockchain transaction, they can present their VC to a verifier (e.g., a verification contract). The verifier verifies the user's identity by checking the validity of the VC issuer's signature and the credential content. However, this scheme has several drawbacks in practical applications. Firstly, due to the customizable nature of VCs, different identity verification authorities can define their own unique VC data structures and content. This forces verifiers to write parsing logic for multiple VC formats into the verification contract to improve compatibility, increasing the contract's complexity and maintenance costs. On the other hand, VCs typically contain authentication data provided by users during identity verification. When a user submits a VC to the blockchain to present to the verifier, this authentication data, which contains user privacy information, is also publicly disclosed and permanently recorded on the blockchain, posing a serious risk of user privacy leakage. Furthermore, a VC is essentially a static data file; VCs publicly displayed on the blockchain may be stolen and reused by third parties, thus creating a risk of identity theft.

[0060] In light of this, the inventors discovered through research that Zero-Knowledge Proof (ZKP) technology can be used to transform user authentication information (generated by the authentication authority based on the hash value of the user's private secret data) into verifiable cryptographic proofs. Simultaneously, an aggregate signature is embedded in the proof data. This aggregate signature is formed by aggregating the sub-signatures of the user's authenticated items and has a corresponding relationship with the public key of the authenticated items. Therefore, without exposing any personal privacy, it is possible not only to prove the authentication status of the user associated with the blockchain account but also to disclose the authenticated items that the user has authenticated, thus balancing the verifiability of the authentication content with the protection of user privacy.

[0061] Based on the above-mentioned technical findings, the inventors have proposed a method for authenticating accounts in a blockchain system in the embodiments of this specification. Figure 3 The following is an implementation framework of the method according to one embodiment. This implementation framework can be divided into two phases: a user authentication phase and an account authentication phase.

[0062] First, let's look at the appendix. Figure 3In the user authentication stage of the illustrated embodiment, referring to ① in Figure 1, the first user authenticates their identity through an identity authentication authority. This involves hashing their private secret data to generate a corresponding hash value. After successful authentication (which can be performed off-chain), corresponding to ② in Figure 1, the hash value of the secret data is added to the corresponding Merkle tree (hereinafter referred to as the authentication Merkle tree) by the identity authentication authority. The root node of the authentication Merkle tree (usually represented by its hash value, corresponding to the second root hash in the attached figure) is then stored in the authentication contract on the blockchain to record that the first user has passed authentication. The identity authentication performed by the identity authentication authority can include several authentication items, such as business information authentication, liveness detection, and card information authentication. Simultaneously, the identity authentication authority can send the Merkle path corresponding to the hash value of the secret data in the authentication Merkle tree to the first user. In subsequent steps, the first user can use this Merkle path and the secret data to generate a zero-knowledge proof.

[0063] Continuing with diagram ③, each authentication item has a corresponding authentication result (e.g., passed, failed, or not executed) and a corresponding key pair. The private key in the key pair is securely stored by the authentication authority, while the public key can be publicly disclosed by the authentication authority. For each authentication item passed by the first user, the authentication authority can use the private key corresponding to that authentication item to sign the first user's first credential, generating a sub-signature corresponding to that authentication item. Corresponding to diagram ④, the first user, based on the specific scenario and a minimum necessary compliance disclosure strategy, can select some or all of the public keys corresponding to the passed authentication items to form a subset of authentication item public keys. Simultaneously, the first user can aggregate the sub-signatures of the authentication items corresponding to each selected public key to generate a first signature.

[0064] Next, let's look at the appendix. Figure 3 In the account authentication stage of the illustrated embodiment, referring to Figure ⑤, after completing user authentication, the first user can generate a zero-knowledge proof based on their private secret data and the Merck path obtained from the authentication authority. The first account address requiring authentication status verification, a subset of the authentication item public key, and the first signature are included in the common input of the zero-knowledge proof. During the generation of the zero-knowledge proof, the root hash of the corresponding Merck tree (shown as the first root hash in the figure) can be calculated based on the hash value of the secret data and the Merck path. This zero-knowledge proof can be used to prove that the first root hash is calculated based on the secret data. The specific generation method of the zero-knowledge proof will be given below and will not be elaborated upon here.

[0065] To verify the identity authentication status of the first user's account address in the blockchain system, the zero-knowledge proof and the first root hash can be packaged into a first transaction and sent to the blockchain node. The first transaction then invokes the verification contract. It's important to understand that the first transaction can be sent by either the holder of the first account address (i.e., the first user) or a second user. Since the first transaction does not contain the first user's secret data, even if the first transaction is sent by a second user, the first user's secret data will not be leaked.

[0066] Next, referring to Figure ⑥, the blockchain node, by executing the verification contract, can verify the zero-knowledge proof based on the first hash. If the zero-knowledge proof passes verification, it checks whether the first hash is the same as the second hash stored in the blockchain system. If they are the same, the first signature can be verified based on the subset of authentication item public keys to check whether the first signature is an aggregation of sub-signatures corresponding to the public keys of each authentication item in the subset. If the first signature passes verification, the various authentication items that the user associated with the first account address has passed are determined based on the public keys of each authentication item in the subset. This allows for account authentication within the blockchain system without disclosing any user privacy, and publicly reveals the authentication items that the user of the account has passed.

[0067] It should be noted that, since the first account address being verified is already included in the public input of the zero-knowledge proof, even if, as mentioned above, the first transaction is sent by the second user (i.e., the second user possesses the zero-knowledge proof), the second user cannot use the zero-knowledge proof to prove other account addresses by tampering with the first account address in the public input, because tampering with the public input would cause the zero-knowledge proof to fail verification.

[0068] Needs to be understood, attached Figure 3 The numbers ①, ②, etc. in the figure are used only as auxiliary markers in the description of the figure and do not have any sequential reference meaning.

[0069] In the embodiments given above, the identity authentication authority can, based on the structural characteristics of the authentication Merk tree, provide users only with the Merk proof (i.e., the Merk path corresponding to the leaf node) of a specific leaf node (i.e., the node corresponding to the user's secret data in the authentication Merk tree). This allows the user to reconstruct the root hash of the authentication Merk tree off-chain based on their secret data and the Merk path, thereby generating the corresponding zero-knowledge proof. Simultaneously, thanks to the irreversible and collision-resistant properties of hash functions, tampering with the data of any leaf node in the authentication Merk tree can cause an irreversible change to the root hash. Since the root hash of the authentication Merk tree has been stored on the blockchain by the identity authentication authority, it possesses tamper-proof characteristics, thus ensuring the credibility of the root hash (i.e., the second root hash) used to represent the user's authentication status. However, it should be understood that in practical applications, the Merk tree is only a preferred cryptographic scheme, not the only choice. With the evolution of cryptographic technology, other cryptographic primitive schemes with irreversible digest verification functions can be used as alternatives, such as multinomial commitments. The technical concepts disclosed in the embodiments of this specification are not limited to the use of specific cryptographic primitives.

[0070] To better understand and illustrate the solutions of the various embodiments of this application, a method for authenticating account identity in a blockchain system will be described in detail below with reference to the accompanying drawings and one or more embodiments. Based on the above technical concept, the specific implementation of the user identity authentication stage will be described first, followed by a method for generating zero-knowledge proofs in one embodiment, and finally, the specific implementation of the account identity authentication stage will be described.

[0071] Figure 4 A timing diagram is shown illustrating a method for authenticating accounts in a blockchain system according to embodiments of this specification. It is understood that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities. Figure 4 As shown, in this embodiment, the method is performed by an identity authentication authority and includes at least the following steps:

[0072] S401: Receive the secret hash corresponding to the secret data sent by the first user, as well as the authentication data.

[0073] The identity verification authority, acting as a trusted third party, is responsible for reviewing and verifying the authentication materials submitted by users and generating corresponding credentials for verified users. In practice, multiple identity verification authorities can coexist. These authorities are typically maintained and audited by a list managed by a decentralized autonomous organization (DAO), and only identity verification provided by authorities listed in this list can be considered trustworthy. Correspondingly, multiple authentication contracts can also be deployed on the blockchain, each associated with a different identity verification authority, to support the coexistence and verification of multi-source identity authentication data.

[0074] In this step, the first user can perform a hash operation on their secret data (e.g., the user's ID number, biometric information, or other private credential data) to generate a corresponding secret hash. This secret hash can serve as an irreversible digest representation of the user's secret data and, together with the authentication data required for identity verification (e.g., ID card, facial image, business license, etc., depending on specific needs), be securely submitted to the identity verification authority for subsequent verification.

[0075] Identity authentication performed by an identity authentication authority can typically be broken down into several sub-authentication items with independent semantics, such as real-name authentication and enterprise qualification authentication. Each sub-authentication item, if it still contains an independently verifiable semantic unit, can be further broken down into smaller-granularity sub-authentication items. For example, real-name authentication can be further broken down into ID card information verification, liveness detection, and face comparison. This decomposition process can be performed recursively, ultimately reducing identity authentication to several basic authentication items that cannot be further decomposed and have clear semantics. These basic authentication items can be called identity authentication items. In user identity authentication, each identity authentication item corresponds to an independent authentication result and a unique key pair (including a public key and a private key).

[0076] After receiving the authentication data from the first user, in step S403, the identity authentication authority can perform KYC identity authentication on the first user based on the authentication data. Upon successful authentication, the authority adds the hash value of the first user's secret data to the authentication Merk tree, updates the root hash of the authentication Merk tree, and stores it on the blockchain system. For each identity authentication item passed by the first user, the corresponding private key can be used to sign the first credential corresponding to the first user, obtaining the corresponding sub-signature. S403 specifically includes at least the following steps:

[0077] In step S4031, the identity authentication authority may perform identity authentication on the first user based on the authentication data, and when the identity authentication is successful, execute step S4033 to add the secret hash to the authentication Merk tree.

[0078] Specifically, identity verification agencies can perform KYC (Know Your Customer) identity verification based on pre-defined compliance standards required by international or regional regulatory laws and regulations, such as those governing anti-money laundering (AML) and combating the financing of terrorism (CFT). This KYC process focuses on verifying the authenticity and legality of the identity, and screening the compliance of the transaction background. It utilizes the authentication data submitted by the first user (e.g., identity documents, facial recognition information, and proof of residence for individual users; business licenses, legal representative identity documents, equity structure descriptions, and statements of fund sources for corporate users). The KYC process includes, but is not limited to, verification of the authenticity of the authentication data (e.g., verifying the validity of identity documents through the public security system, and verifying the consistency between facial recognition information and document photos), review of the legality of the authentication data (e.g., confirming the company's operating qualifications, checking whether the user belongs to a sanctioned list or a high-risk area), and necessary due diligence (e.g., verifying the source of funds and understanding the purpose of the transaction).

[0079] If the first user successfully completes KYC authentication, the authentication authority can insert the first user's secret hash as a new leaf node into the authentication Merk tree maintained by the authority, and update the root hash of the authentication Merk tree. The authentication Merk tree is constructed based on cryptographic mechanisms, ensuring that each leaf node corresponds to a unique Merk path, and any change to a node will trigger a change in the hash value of the root node of the authentication Merk tree. Therefore, the root hash of the authentication Merk tree can be used to represent the success status of the first user's KYC authentication completed by the authentication authority, providing a reliable verification basis for subsequent on-chain account authentication.

[0080] After adding the secret hash of the first user to the authentication Merk tree, step S4035 can be executed, in which the identity authentication authority updates the authentication Merk tree to obtain the root hash corresponding to the root node of the authentication Merk tree, and stores the root hash in the blockchain system.

[0081] In this step, the identity authentication authority can send an authentication transaction to the blockchain system, invoking the authentication contract deployed on the blockchain system to persistently record the new root hash of the authentication Merkle tree in the distributed ledger of the blockchain system. In other words, the authentication transaction contains the root hash of the authentication Merkle tree, which is used to store the root hash in the contract state of the authentication contract. It is easy to see that after the identity authentication authority processes the identity authentication of multiple users, the state data of the authentication contract stored in the blockchain system is a list composed of the root hashes of multiple updated versions of the authentication Merkle tree maintained by the identity authentication authority. In other words, when the identity authentication authority authenticates a new user and updates the root hash of the authentication Merkle tree, it will add the new root hash to the contract state of the authentication contract, while completely saving the root hashes of all historical versions, without overwriting the previously stored historical version root hashes. This also means that every user who has passed KYC identity authentication by the identity authentication authority can find the root hash of the authentication Merkle tree corresponding to the moment they completed KYC identity authentication in the contract state of the authentication contract. Therefore, even if new users subsequently pass KYC verification by the identity verification authority and update the root hash of the certified Merck tree, users who have already completed KYC verification do not need to undergo re-verification. Their corresponding historical version of the certified Merck tree root hash remains stored in the blockchain's verification contract. Leveraging the immutability of the blockchain, the certified Merck tree root hash stored on it serves as a cryptographic digest of the set of all verified users, possessing a high degree of trustworthiness.

[0082] Next, in step S4037, the identity authentication authority can use its corresponding authentication item private key to sign the first credential corresponding to the first user for any first identity authentication item that has passed the authentication, thereby generating a sub-signature corresponding to the first identity authentication item.

[0083] Specifically, the first credential can consist of one or more cryptographic elements used to associate and bind a user with their authenticated credentials. Typically, the first credential includes the root hash of the authentication Merkle tree and the secret hash. The combination of these two can be a simple data concatenation, or the data can be concatenated first and then the hash value calculated, which is then used as the first credential. Including the root hash of the authentication Merkle tree ensures that the first credential is associated with the authentication status of the current user (the first user) by the authentication authority, while including the secret hash ensures that the first credential corresponds to the current user. Therefore, signing the first credential using the private key corresponding to the authentication item essentially constitutes a cryptographic statement by the authentication authority regarding the specific authentication item passed by the current user in the authentication process performed by the authority.

[0084] Finally, in step S4039, the identity authentication authority may send the sub-signature corresponding to each of the passed identity authentication items, and the secret hash corresponding to the Merck path in the authentication Merck tree, to the first user.

[0085] The Merck path consists of the hashes of all sibling nodes along the path from the leaf node containing the secret hash to the root node. Based on this Merck path, the first user can calculate and reconstruct the root hash of the certified Merck tree. Furthermore, without revealing the original secret data, they can generate a zero-knowledge proof off-chain to demonstrate that they possess the secret data necessary to construct the root hash of the certified Merck tree. Sending each sub-signature to the first user allows them to independently select the identity authentication items to be disclosed based on the compliance requirements of the specific scenario, aggregating the corresponding sub-signatures into a single key.

[0086] Through the above steps, after the first user's identity is authenticated by the identity authentication authority, they possess the sub-signatures corresponding to each authentication item the user has successfully completed, returned by the authority, as well as the Merk path corresponding to the user's secret data hash value in the certified Merk tree. The root hash of this certified Merk tree has been stored on the blockchain by the identity authentication authority. Next, in order to complete the identity authentication of the account in the blockchain system without revealing their secret data, the first user can use their trusted user device (e.g., a personal computer or secure hardware module) to locally generate a cryptographic proof based on zero-knowledge proof technology to verify that the secret data they hold can construct the root hash of the certified Merk tree.

[0087] Figure 5 A timing diagram is shown illustrating a method for authenticating accounts in a blockchain system according to embodiments of this specification. It is understood that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities. Figure 5 As shown, in this embodiment, the method is executed by the user equipment of the first user and includes at least the following steps:

[0088] Steps S501 and S503: First data provided by the first user is input into the first circuit. The first circuit is constructed based on a zero-knowledge proof framework. The first data includes at least a first Merkle path and first secret data as private input (also known as witness information), a first account address, a subset of authentication item public keys, and a first signature as public input. The first signature is an aggregate signature of the sub-signatures corresponding to each authentication item public key in the subset of authentication item public keys. Each of the sub-signatures is generated by the identity authentication authority signing the first credential corresponding to the first user. The authentication item public key corresponds to the identity authentication item of the identity authentication authority.

[0089] The entire process of generating a zero-knowledge proof (ZKP) relies on a special program (called a circuit, or first circuit in this embodiment) that differs from a regular computer program. This program consists of constraints that encode computational logic of interest to the user, such as proving that "the prover possesses the original data corresponding to a certain hash value." Creating a zero-knowledge proof aims to prove that there exists a set of private inputs such that when substituted into the circuit along with given public inputs, all constraints are satisfied. To verify a zero-knowledge proof, the verifier can run a standard verification algorithm that takes a brief zero-knowledge proof, a verification key, and the public inputs as input and determines the validity of the proof with a cryptographically high degree of confidence. The verification key is generated based on the circuit during the trusted setup phase, implicitly containing the circuit's constraint information. Therefore, the verifier does not need to access the original circuit itself to verify the zero-knowledge proof.

[0090] The first circuit is a pre-designed computational model for implementing specific proof logic, typically represented as an arithmetic circuit. First circuits are built upon zero-knowledge proof frameworks, such as zk-SNARK or zk-STARK. As discussed above, zero-knowledge proof refers to a prover's ability to convince a verifier that a statement is true without providing any private information. In other words, the prover generates a proof of a statement using witness information possessed only by themselves. The verifier can verify the proof to determine that the prover possesses the witness to that statement, while simultaneously being unable to obtain any information about that witness.

[0091] In this step, the first user can use their private first secret data and the first Merkle path obtained from the identity authentication authority as privacy inputs, and the first account address, a subset of the authentication item public key, and the first signature as public inputs, encapsulating them into first data, and inputting it into the first circuit through the user device. It should be noted that the first user needs to provide the original first secret data to the first circuit, rather than the secret hash, because the first circuit needs to ensure that the first user is the original holder of the first secret data, not a forwarder of the secret hash, when subsequently generating zero-knowledge proofs, to prevent malicious users from stealing the secret hash to forge the first user's zero-knowledge proofs.

[0092] After the first data is input into the first circuit, the following steps can be performed through the first circuit:

[0093] Step S505: Perform hash calculation on the first secret data to obtain the secret hash; use the secret hash as the leaf node and calculate the first root hash based on the first Merck path.

[0094] The first circuit can perform a hash calculation on the first secret data provided by the first user to obtain the corresponding secret hash. Typically, the hash algorithm used by the first circuit is consistent with the hash algorithm used by the first user when performing user authentication (e.g., both are SHA-256 algorithms) to ensure that the secret hash is completely consistent with the secret hash previously submitted to the authentication authority and stored in the authentication Merck leaf node.

[0095] Subsequently, the first circuit calculates the parent node hash level by level upwards based on the secret hash and the first Merck path, according to the construction rules of the Merck tree, and finally calculates the first root hash of the root node.

[0096] In one alternative implementation, the first data can be processed by a separately deployed witness generator, and the generated structured witness information can then be input into the first circuit for subsequent calculations. This improves circuit efficiency and reduces circuit construction costs. The witness generator and the first circuit are designed based on the same zero-knowledge proof framework and can reside within the trusted environment of the first user device, ensuring data security by eliminating the need for the witness generator to transmit any private data. The witness generator can receive the first data provided by the user (including private and public inputs), perform data formatting (e.g., converting to a circuit-compatible format) and data calculations (e.g., calculating secret hashes and the first root hash), and encapsulate it into structured witness information before transmitting it to the first circuit.

[0097] Next, in step S507, a zero-knowledge proof is generated, which includes a first account address, a subset of the authentication item public key, and a first signature. The zero-knowledge proof is used to prove that the first root hash is calculated based on the first secret data.

[0098] After reconstructing the first hash, the first circuit can further invoke a zero-knowledge proof generation algorithm to generate a corresponding zero-knowledge proof. The first account address, the subset of the authentication item's public key, and the first signature are included as public inputs in the zero-knowledge proof. This zero-knowledge proof can prove to the verifier that the first user possesses the first secret data corresponding to the specified Merck path, and that the first hash can be correctly calculated from this first secret data.

[0099] In a preferred embodiment, the first circuit operates offline within the trusted environment of the first user's user equipment. The aforementioned computation process can be completed entirely within the first circuit to ensure the generation of zero-knowledge proofs without exposing first secret data or transmitting any private data externally.

[0100] In one specific implementation, the first data input to the first circuit may further include an authentication root hash. Before the first circuit generates a zero-knowledge proof, the locally reconstructed first root hash can be compared with the authentication root hash input by the first user. If the first root hash is the same as the authentication root hash, the zero-knowledge proof is generated.

[0101] After generating the zero-knowledge proof, the first user can use this proof to authenticate their account in the blockchain system. Therefore, the first user's device can execute step S509, sending a first transaction to the blockchain system. This first transaction invokes a verification contract and includes first proof data. The first proof data includes at least the zero-knowledge proof and a first root hash.

[0102] The verification contract is used to verify the zero-knowledge proof. If the zero-knowledge proof verification passes, it determines whether the first root hash is the same as the second root hash stored in the blockchain system. The second root hash is uploaded by the identity authentication authority and is the root hash of the authentication Merk tree. The authentication Merk tree is constructed by the identity authentication authority based on the hash values ​​of the secret data of multiple authenticated users. If the first and second root hashes are the same, the first signature is verified based on the subset of the authentication item's public key. The specific execution method of the verification contract will be described in detail in the following embodiments, and will not be elaborated here. The above identity authentication process effectively avoids the leakage of sensitive information such as user secret data or the authentication Merk tree's Merk path, while ensuring the reliability of the conclusion. Simultaneously, by using the aggregated signature mechanism, the user's passed identity authentication items are made public in the form of a single signature and a corresponding subset of the authentication item's public key. This allows the verifier to determine the user's passed identity authentication items based on the subset of the authentication item's public key, but prevents the reverse recovery of the sub-signatures corresponding to each identity authentication item or the plaintext data used for signing. Therefore, while ensuring full protection of user privacy data, it is possible to verify the identity of accounts in the blockchain system in accordance with compliance disclosure requirements, and disclose the identity verification items that the user to which the account belongs has passed.

[0103] It should also be noted that the secret hash used by the identity authentication authority when updating the authentication Merck tree is provided by the user. Therefore, the identity authentication authority cannot know the first secret data corresponding to the secret hash. In other words, since generating a zero-knowledge proof requires the first user's first secret data as a privacy input, even if the identity authentication authority acts maliciously, it cannot forge the first user's zero-knowledge proof without knowing the first secret data.

[0104] Through the steps described above, after the first user's identity is verified by the identity verification authority, they can generate a zero-knowledge proof based on the Merck path obtained from the authority and their private secret data. Simultaneously, the first user obtains the sub-signatures corresponding to each verified identity item from the identity verification authority. Next, the first user can use this zero-knowledge proof to complete the identity verification process for the account in the blockchain system and can use the sub-signatures to publicly disclose the verified identity items to the verifier.

[0105] Figure 6 A timing diagram is shown illustrating a method for authenticating accounts in a blockchain system according to embodiments of this specification. It is understood that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities. Figure 6 As shown, in this embodiment, the method is executed by a node of the blockchain system and includes at least the following steps:

[0106] Step S601: Obtain the first transaction. The first transaction invokes the verification contract and contains first proof data. The first proof data includes at least a zero-knowledge proof and a first root hash. The zero-knowledge proof is used to prove that the first root hash is calculated based on the first secret data input by the first user. The public input of the zero-knowledge proof includes a first account address, a subset of authentication item public keys, and a first signature. The first signature is an aggregate signature of the sub-signatures corresponding to each authentication item public key in the subset of authentication item public keys. Each of the sub-signatures is generated by the identity authentication authority signing the first credential corresponding to the first user. The authentication item public key corresponds to the identity authentication item of the identity authentication authority.

[0107] The first transaction encapsulates a zero-knowledge proof generated locally by the first user, and a first root hash reconstructed and calculated based on the first user's first secret data and the Merck path. The public inputs of the zero-knowledge proof include the first account address, a subset of the authentication item public key, and the first signature. The generation process of the first root hash and the zero-knowledge proof has been described above and will not be repeated here.

[0108] The subset of authentication item public keys is either a subset or the entire set of authentication item public keys. The set of authentication item public keys contains the authentication item public keys corresponding to each authentication item that the first user has passed with the authentication authority. This set of authentication item public keys can be provided by the authentication authority after the user completes authentication, or it can be constructed by the first user based on their passed authentication items and the pre-disclosed correspondence between authentication items and authentication item public keys provided by the authentication authority. This specification does not specifically limit this approach in the embodiments.

[0109] In practice, the first user can follow the principle of minimum and necessary disclosure, and select a combination of public keys from the set of authentication item public keys to form the subset of authentication item public keys, based on the specific needs of the scenario (e.g., the compliance requirements of the verification party). For example, if the first user has passed three authentication items at an identity authentication authority: ID card information verification (corresponding to authentication item public key PK1), face comparison (corresponding to authentication item public key PK2), and fingerprint verification (corresponding to authentication item public key PK3), the set of authentication item public keys formed by these authentication item public keys can be understood as {PK1, PK2, PK3}. If the verification party only requires the user to pass two-factor authentication, the first user can arbitrarily select two authentication item public keys from the set of authentication item public keys (the authentication item public keys that meet the verification party's authentication requirements) to form the subset of authentication item public keys. For example, the subset of authentication item public keys can be PK1 and PK2, PK2 and PK3, or PK1 and PK3 (assuming that any of the above authentication item public key combinations corresponds to an authentication item combination that can meet the verification party's identity authentication requirements). If the verifier requires two-factor authentication and ID card information verification is mandatory, the first user needs to select PK1 and can choose any other authentication item public key to form a subset of authentication item public keys. That is, the subset of authentication item public keys can be PK1 and PK2, or PK1 and PK3.

[0110] The first signature is an aggregate signature, which can be a single signature obtained by the first user through cryptographic aggregation of the sub-signatures corresponding to the public keys of each selected authentication item. The sub-signatures are generated by the authentication authority using the private key of the authentication item corresponding to the authentication item to sign the first credential containing the user's identity credentials and user authentication status credentials (such as the root hash and secret hash combination described earlier). This part has been detailed above and will not be elaborated further here. In this embodiment, the first credential may include: the hash values ​​of the first root hash and the first secret data. The first user can use an aggregate signature algorithm (e.g., the BLS algorithm) to aggregate the sub-signatures of the authentication items corresponding to the public keys of each selected authentication item subset into a single aggregate signature, i.e., the first signature.

[0111] Because the aggregate signature algorithm is one-way, the first signature is irreversible. This means that no third party (including the verifier) ​​can reconstruct the individual sub-signatures from the aggregated first signature. This characteristic allows the first signature to be securely propagated and verified within the blockchain system, effectively preventing the risk of signature disassembly, tampering, or impersonation. Furthermore, the first signature is not affected by the number of its sub-signatures and can have a controllable or fixed encoding length, thereby saving storage space in the blockchain system, reducing the computational overhead of transaction verification, and improving verification efficiency.

[0112] Returning to the main process, after receiving the first transaction, the node can invoke the verification contract to execute step S603 based on the first transaction, verifying the zero-knowledge proof and the first signature. Upon successful verification, it determines the verified identity authentication item for the first account address based on the subset of the authentication item's public key. S603 specifically includes at least the following steps:

[0113] Step S6031: Verify the zero-knowledge proof based on the first root hash. If the zero-knowledge proof verification passes, proceed to step S6033: Determine if the first root hash is the same as the second root hash stored in the blockchain system. The second root hash is uploaded by the identity authentication authority and is the root hash of the authentication Merk tree, which is constructed by the identity authentication authority based on the hash values ​​of the secret data of multiple authenticated users. If the first and second root hashes are the same, proceed to step S6035: Verify the first signature based on the subset of the authentication item public key. If the first signature verification passes, proceed to step S6037: Determine the authentication item for the first account address that has passed authentication based on the subset of the authentication item public key. A detailed explanation follows.

[0114] The node executes the first transaction and invokes a verification contract. This contract uses a pre-built verification algorithm and corresponding verification key to validate the zero-knowledge proof, confirming its validity. Specifically, it proves that the generator (prover) of the zero-knowledge proof possesses the secret data required to generate the first hash and that the calculation process is correct. After the zero-knowledge proof is verified, the verification contract is executed to further compare the first hash in the first transaction with the second hash stored in the blockchain system. The second hash is stored by an identity authentication authority. If they match, it indicates that the first hash originates from the authentication Merkle tree maintained by the identity authentication authority, and it can be inferred that the user holding the corresponding secret data (the first secret data) has completed identity authentication with that authority.

[0115] According to one implementation, to prevent zero-knowledge proofs from being verified by unrelated verification contracts, the first proof data used for account authentication may further include an authorization address. Before executing the first transaction to invoke the verification contract, the verification contract address corresponding to the verification contract can be checked. If the verification contract address is the same as the authorization address, the verification contract is executed; otherwise, the execution of the verification contract is terminated.

[0116] According to one implementation, in scenarios with multiple authentication authorities, to quickly locate the second root hash, the first proof data used for account authentication may further include an institution identifier corresponding to the authentication authority (the institution that authenticates the first user); the authentication Merk tree corresponds to the institution identifier. That is, when performing a consistency comparison between the first and second root hashes, the root hash of the authentication Merk tree maintained by the institution that authenticated the first user can be quickly and accurately located in the blockchain system based on the institution identifier contained in the first proof data, thereby improving the retrieval efficiency of the second root hash.

[0117] Furthermore, during the aforementioned identity authentication process, the verification contract utilizes a pre-built verification algorithm to verify the zero-knowledge proof in the first proof data. Referring to the preceding description of the zero-knowledge proof generation process, the zero-knowledge proof is generated by the first user inputting their private first secret data and the corresponding Merk path in the authentication Merk tree into the zero-knowledge proof circuit (i.e., the first circuit mentioned earlier). Therefore, to ensure that the verification contract can correctly verify the zero-knowledge proof, the verification contract includes a verification algorithm corresponding to the first circuit. The verification contract pre-stores the verification key (VK) under the zero-knowledge proof algorithm, and the proof key (PK) cannot be reverse-derived, thereby ensuring that even if the bytecode of the verification contract is made public, attackers cannot forge a valid zero-knowledge proof.

[0118] Based on the previous explanation of the method by which identity authentication authorities store the authentication Merck root hash in the blockchain system, it can also be understood that, before determining whether the first hash is the same as the second hash stored in the blockchain system, in order to obtain the second hash, the blockchain node can obtain the second hash stored in the contract state of the authentication contract by executing the authentication contract called by the verification contract.

[0119] The above describes the process of verifying zero-knowledge proofs and the first root hash. If the verification is successful, the blockchain node can verify the first signature based on the subset of the public key of the authentication item.

[0120] As previously stated, the first signature is an aggregated signature of the sub-signatures corresponding to the public keys of each authentication item in the subset of authentication item public keys. Verifying the first signature can be used to determine whether the first user possesses a sub-signature generated by the identity authentication authority and corresponding to the public keys of each authentication item in the subset of authentication item public keys.

[0121] Blockchain nodes can execute the verification contract to first aggregate the public keys of each authentication item in the subset of authentication item public keys to obtain an aggregated public key. Then, using the aggregated public key, based on the first credential, they can verify the first signature to determine whether the first signature can be correctly verified by the subset of authentication item public keys.

[0122] If the signature verification is successful, it can be determined that the first user possesses the sub-signatures issued by the identity authentication authority corresponding to the public keys of each authentication item in the subset of authentication item public keys (because only correct sub-signatures can be aggregated to form an aggregate signature that can be verified by the corresponding public key subset), which also indirectly proves that the first user has passed the authentication of the identity authentication items corresponding to the public keys of each authentication item in the subset of authentication item public keys.

[0123] Next, if the first signature verification passes, the blockchain node can determine the identity authentication item that the first account address has passed based on the subset of the authentication item public key.

[0124] By executing the verification contract to query the preset "authentication item public key - identity authentication item" correspondence, each authentication item public key in the subset of authentication item public keys can be parsed into a specific identity authentication item (for example, authentication item public key PK1 corresponds to "ID card information verification", authentication item public key PK2 corresponds to "face comparison", and authentication item public key PK3 corresponds to "fingerprint verification"), thereby accurately determining the identity authentication item that the first account address has passed.

[0125] In practice, identity authentication authorities can pre-publish the various authentication items they can execute and their corresponding public keys. For example, the "authentication item public key - identity authentication item" mapping (hereinafter referred to as the first mapping) can be reliably stored in an authentication contract on the blockchain. The blockchain node can obtain the set of first mappings belonging to the identity authentication authority from the contract state of the authentication contract by executing the authentication contract called by the verification contract. The first mapping set contains several first mappings, each representing the mapping between an identity authentication item and its public key. By matching each public key in the subset of public keys with the first mapping, the identity authentication items for the first account address that have been verified are determined.

[0126] In an optional embodiment, if the authentication items passed by the first user satisfy the preset authentication constraints, the authentication status corresponding to the first account address can be recorded as "authenticated". Typically, the authentication status corresponding to the first account address can be updated in the contract status of the verification contract. The authentication constraints can be a set of authentication logic rules preset by the verifier, such as requiring authentication of at least a few authentication items (such as the two-factor authentication mentioned above), or authentication of a specific combination of several authentication items.

[0127] The preceding text details a method for account authentication in a blockchain system. This method can be applied to various blockchain business scenarios that require balancing identity authentication compliance with user privacy protection, including but not limited to blockchain financial asset trading, transfers, payments, and clearing. Taking the transfer transaction in the decentralized finance scenario described above as an example... Figure 7 This illustrates a process for authenticating an account in an exemplary transfer transaction.

[0128] See appendix Figure 7 User A holds account A in the blockchain system, and user B holds account B in the same system. When account A initiates a transfer to account B, the corresponding transfer transaction is submitted to the blockchain node (the dotted lines in the attached diagram indicate logical connections, and solid lines indicate contract calls or data flows). To ensure that the transfer transaction meets compliance requirements, the blockchain node can decide whether to allow the transfer to be executed based on the identity authentication status of the participants.

[0129] Taking the scenario of verifying the identity authentication status of account B as shown in the attached diagram as an example, the blockchain node receives a transfer transaction. This transaction includes transfer information, which indicates the participants in the transfer of financial assets (transferring account, receiving account) and transaction information such as the amount transferred. See attached diagram. Figure 7 The transfer information indicates that a first amount of financial assets (included in the first asset) will be transferred from account A (the sending account) to account B (the receiving account). Figure 7 In the given example, the first quantity is 4, meaning the first asset includes 4 units of financial assets. The transfer transaction invokes a verification contract to verify the identity authentication status of the participating accounts in the transfer transaction. As mentioned earlier, in the stablecoin scenario, only verifying the real user identity of the receiving account is needed to form a complete compliance chain for the circulation of stablecoins. Therefore, in this scenario, the verification contract can be invoked to verify only the identity authentication status of the receiving account in the transfer transaction. In specific practical scenarios, the verification of the identity authentication status of the participating accounts in the transfer transaction can also be implemented as verification of both the receiving and sending accounts, depending on specific needs. In the following text, the passing condition for verifying the identity authentication status of the participating accounts is referred to as the first condition, that is, the first condition is one of the following: the receiving account of the transfer transaction passes identity authentication, or both the receiving and sending accounts of the transfer transaction pass identity authentication.

[0130] Please refer to the appendix for further details. Figure 7The system executes the transfer transaction and invokes a verification contract to verify whether the participating accounts have passed identity authentication. If a first condition is met (represented by the "Pass" branch in the attached diagram), the transfer is executed based on the transfer information. If the first condition is not met (represented by the "Fail" branch in the attached diagram), the first asset (containing the first amount of financial assets to be transferred) of the sending account (account A in this example) can be frozen. An event with a specific title is recorded in the receipt (or contract status) of the transfer transaction. This event may include the account to be verified, the freezing time information, and the information awaiting transfer, and the execution of the transfer transaction ends. The freezing time information includes, for example, the start time and duration of the freeze; the information awaiting transfer includes, for example, information indicating that account A is about to transfer the first asset to account B. This freezing operation can be implemented by invoking a specific smart contract, such as a time-lock contract deployed in a blockchain system, or by invoking a function (e.g., a time-lock function) in the management contract corresponding to the financial asset.

[0131] To achieve flexible control over financial assets, a pre-defined time period (first time period) can be preset when freezing financial assets. During the first time period of freezing the first asset, a pre-set computing device or service (such as a decentralized oracle network, Chainlink Keeper service, etc.) can automatically send transactions (i.e., second transactions) to the blockchain system based on the events recorded in the blockchain system, at predefined time intervals or at specific time points. The second transaction can call a verification contract, which can also call a time lock contract and a transfer contract to complete the task corresponding to the event. After receiving the second transaction, the blockchain system can execute the second transaction to call the verification contract, verify the identity authentication status of the account to be verified (the account of the participant in the transfer transaction) recorded in the above event, and give a conclusion on whether to allow the transfer of the first asset based on the verification result.

[0132] In one implementation, a second transaction can be periodically sent to the blockchain system at fixed time intervals until the first condition is met within the first time period, or until the first time period expires. This allows for near real-time capture of updates to the blockchain account's authentication status, enabling immediate transfer completion when the first condition is met, minimizing asset freeze time and improving user experience and fund transfer efficiency. In another implementation, a second transaction can be initiated at the end of the first time period for final status verification. This method saves computational resources and transaction fees by reducing the number of on-chain transactions and is suitable for scenarios where timeliness of transfers is not critical.

[0133] During the freeze period, the first asset remains with the transferring account of the transaction (account A in this example), but is in a non-consumable state, ensuring that double-spending will not occur regardless of the subsequent identity verification results. The aforementioned process of calling the verification contract to verify the identity verification status of the participants in the transaction, and updating the identity verification status, can be found in the methods and procedures given in the previous embodiments, and will not be repeated here.

[0134] Please refer to the appendix for further details. Figure 7 If the first condition is met within the first time period (represented by the "Pass" branch in the attached diagram), the first asset can be unfrozen and a transfer can be executed according to the transfer information. For example, the specific execution method of this process can be to first call the unlock contract to unfreeze the frozen first asset, and then execute the transfer contract corresponding to the financial asset according to the transfer information to complete the transfer. It can be understood that the above unfreezing and transfer operations can also be implemented by calling functions (e.g., unlock function, transfer function) in the management contract corresponding to the financial asset.

[0135] If the first time period expires and the first condition is not met (which can also be understood as the first time period expiring and the transfer not being executed), the first asset can be unfrozen. This process can be, for example, by calling the unlock contract (or the unlock function in the management contract corresponding to the financial asset) to unfreeze the frozen first asset, thereby keeping the first asset in the sending account of the transfer transaction.

[0136] It should be noted that when the financial asset is not a native financial asset, such as the stablecoin mentioned above (or other on-chain assets issued based on ERC-20, ERC-721, etc. standards), its circulation relies on the corresponding management contract (such as a stablecoin issuance contract). The ownership of the financial asset is not stored in an external account, but is recorded by the management contract through an internally maintained "account address-balance" mapping, such as mapping(address=>uint256). This mapping clarifies the financial asset holdings of each account. When an external account queries its balance, it can also call the BalanceOf function of the management contract to read the corresponding balance value in the mapping. In the above embodiment, the transfer based on transfer information can specifically be that the blockchain node calls the transfer function in the management contract corresponding to the financial asset, and modifies the "account address-balance" mapping data stored in the management contract according to the transfer information to complete the transfer. For example, in the management contract corresponding to the financial asset, the balance associated with the account address of the transferring account is deducted by a first amount, and the balance associated with the account address of the transferring account is increased by a first amount.

[0137] In the account identity verification process described above, when the sender initiates a transfer to the receiver, the system does not interrupt the transaction or require the sender to verify the receiver's identity. Instead, a smart contract automatically and asynchronously verifies the on-chain identity verification status of the receiver or both parties in the transaction. This verification status is updated based on the off-chain verification results using zero-knowledge proof technology, effectively preventing the leakage of users' confidential data. This mechanism ensures the smoothness of transfer operations in the blockchain system; the sender does not need to pay attention to the identity verification status of the transaction participants. Users can use zero-knowledge proof technology to prove to the blockchain verification contract that the accounts of the transaction participants they own have passed off-chain identity verification, while hiding their original confidential data.

[0138] The above-described method for account authentication in a blockchain system can complete account authentication without disclosing any user privacy. By leveraging zero-knowledge proof technology, the user's authenticated information is transformed into a verifiable cryptographic proof. Simultaneously, an aggregate signature is embedded in the proof data. This aggregate signature is formed by aggregating the sub-signatures of the user's authenticated items and corresponds to the public key of those items. Therefore, without exposing any personal privacy, it can not only prove the successful authentication status of the user associated with the blockchain account but also disclose the authenticated items the user has passed, thus balancing the verifiability of the authentication content with user privacy protection.

[0139] In this specification, the terms "first" in the first transaction, the first root hash, etc., and the corresponding terms "second" and "third" (if they exist) in the text are merely for the convenience of distinction and description, and do not have any limiting meaning.

[0140] The foregoing description describes specific embodiments of this specification; other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than those shown in the embodiments, and the desired result may still be achieved. Furthermore, the processes depicted in the drawings do not necessarily need to follow the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0141] This specification also provides a computing device in its embodiments, including a memory and a processor. The memory stores computer programs / instructions, and when the processor executes the computer programs / instructions, it implements the methods in the foregoing embodiments.

[0142] 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.

[0143] 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.

[0144] 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.

[0145] 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.

[0146] 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.

[0147] 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.

[0148] 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.

[0149] 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.

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

[0151] 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.

[0152] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 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.

[0153] 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.

[0154] 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 distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0155] 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.

[0156] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments 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 method for authenticating accounts in a blockchain system, executed by nodes of the blockchain system, comprising: The first transaction is obtained, which calls the verification contract and contains first proof data. The first proof data includes at least a zero-knowledge proof and a first root hash. The zero-knowledge proof is used to prove that the first root hash is calculated based on the first secret data input by the first user. The public input of the zero-knowledge proof includes a first account address, a subset of authentication item public keys, and a first signature. The first signature is an aggregate signature of the sub-signatures corresponding to each authentication item public key in the subset of authentication item public keys. Each of the sub-signatures is generated by the identity authentication authority signing the first credential corresponding to the first user. The authentication item public key corresponds to the identity authentication item of the identity authentication authority. Based on the first transaction, the verification contract is invoked to perform the following steps: verify the zero-knowledge proof based on the first root hash; if the zero-knowledge proof verification passes, determine whether the first root hash is the same as the second root hash stored in the blockchain system, the second root hash being uploaded by the identity authentication authority and being the root hash of the authentication Merk tree, the authentication Merk tree being constructed by the identity authentication authority based on the hash values ​​of the secret data of multiple users who have passed identity authentication; if the first root hash and the second root hash are the same, verify the first signature based on the subset of the authentication item public key; if the first signature verification passes, determine the first account address has passed the identity authentication item based on the subset of the authentication item public key.

2. The method according to claim 1, wherein, The method further includes: If the verified identity authentication item satisfies the preset authentication constraints, the identity authentication status corresponding to the first account address is recorded as a verified identity authentication status in the contract status of the verification contract.

3. The method according to claim 1, wherein, The first credential includes the hash value of the first root hash and the hash value of the first secret data.

4. The method according to claim 1, wherein, The subset of authentication item public keys is selected by the first user from the set of authentication item public keys, which is received from the identity authentication authority and includes the authentication item public keys corresponding to the authentication items that the first user has passed with the identity authentication authority.

5. The method according to claim 1, wherein, The authentication items that have been verified for the first account address are determined based on the subset of the authentication item public key, including: By executing the authentication contract called by the verification contract, a first mapping set belonging to the identity authentication authority is obtained from the contract state of the authentication contract. This set contains several first mappings, and any first mapping is used to represent the correspondence between the identity authentication item and the authentication item public key. Based on the first mapping set and the subset of the authentication item public keys, the authentication items that the first account address has passed are determined.

6. The method according to claim 1, wherein, Verifying the first signature based on the subset of the authentication item's public key includes: Based on the subset of public keys for the authentication items and the first credential, the first signature is verified to determine whether the first user possesses a sub-signature generated by the identity authentication authority and corresponding to each public key for the authentication items in the subset of public keys for the authentication items.

7. The method according to claim 1, wherein, The zero-knowledge proof is generated by a first user based on first secret data through a zero-knowledge proof circuit, and the verification contract includes a verification algorithm corresponding to the zero-knowledge proof circuit.

8. The method according to claim 1, wherein, The method further includes: Receive a transfer transaction, the transfer transaction including transfer information, used to indicate a transfer out of or into a first account address a first amount of financial assets, the financial assets being issued through a smart contract, the transfer transaction invoking the verification contract; By executing the transfer transaction and invoking the verification contract, it is determined whether the participating accounts of the transfer transaction have passed identity verification. If a first condition is met, the transfer is executed according to the transfer information. The first condition is one of the following: the receiving account of the transfer transaction has passed identity verification, or both the receiving account and the sending account of the transfer transaction have passed identity verification.

9. The method according to claim 8, wherein, Determining whether the participating accounts of the transfer transaction have passed identity verification by executing the verification contract includes: If the first condition is not met, the first asset of the transfer-out account of the transfer transaction shall be frozen; the first asset includes a first quantity of financial assets. By executing the second transaction to invoke the verification contract, if the first condition is met within the first time period, the first asset is unfrozen and the transfer is executed according to the transfer information; otherwise, the first asset is unfrozen.

10. A method for authenticating accounts in a blockchain system, performed by an identity authentication authority, comprising: Receive the secret hash corresponding to the secret data sent by the first user, as well as the authentication data; Based on the authentication data, identity authentication is performed on the first user, and when the identity authentication is successful, the secret hash is added to the authentication Merk tree. The identity authentication includes several identity authentication items. Update the certified Merck tree to obtain the root hash corresponding to the root node of the certified Merck tree, and store the root hash in the blockchain system; For any first identity authentication item that has been passed, use its corresponding authentication item private key to sign the first credential corresponding to the first user and generate a sub-signature corresponding to the first identity authentication item. The sub-signature corresponding to each of the passed identity authentication items, and the Merk path corresponding to the secret hash in the authentication Merk tree, are sent to the first user.

11. A method for authenticating an account in a blockchain system, performed by a first user's user device, the method comprising: First data provided by a first user is input into a first circuit. The first circuit is constructed based on a zero-knowledge proof framework. The first data includes at least a first Merkle path and first secret data as privacy inputs, and a first account address, a subset of authentication item public keys, and a first signature as public inputs. The first signature is an aggregate signature of the sub-signatures corresponding to each authentication item public key in the subset of authentication item public keys. Each of the sub-signatures is generated by signing the first credential corresponding to the first user by an identity authentication authority. The authentication item public key corresponds to the identity authentication item of the identity authentication authority. The first circuit performs the following steps: hashing the first secret data to obtain a secret hash; using the secret hash as a leaf node, and based on the first Merck path, calculating the first root hash; Generate a zero-knowledge proof, which includes a first account address, a subset of the authentication item public key, and a first signature. The zero-knowledge proof is used to prove that the first root hash is calculated based on the first secret data. A first transaction is sent to the blockchain system. The first transaction invokes a verification contract and includes first proof data, which includes at least the zero-knowledge proof and a first root hash. The verification contract is used to verify the zero-knowledge proof. If the zero-knowledge proof is verified successfully, it determines whether the first root hash is the same as a second root hash stored in the blockchain system. The second root hash is uploaded by the identity authentication authority and is the root hash of the authentication Merk tree. The authentication Merk tree is constructed by the identity authentication authority based on the hash values ​​of the secret data of multiple authenticated users. If the first root hash and the second root hash are the same, a first signature is verified based on a subset of the authentication item's public key.

12. A computing device comprising a memory and a processor, wherein the memory stores a computer program, and the processor, when executing the computer program, implements the method of any one of claims 1-11.

Images