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

Abstract

The method for performing identity authentication on the account in the block chain system is executed by a node of the block chain system, and comprises the following steps: acquiring a first transaction which comprises first proof data which comprises zero knowledge proof and first root hash, 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, and the public input of the zero-knowledge proof comprises a first account address. The verification contract is called based on the first transaction to execute the following steps: verifying the zero knowledge proof based on the first root hash; under the condition that the verification is passed, whether the first root hash is the same as a second root hash stored in the block chain system is determined, 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 first root hash is the same as the second root hash, recording an identity authentication state corresponding to the first account address as an identity authentication passing state in a contract state of the verification contract.

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). Their core objective is to require financial service providers to verify the identities of account holders participating in financial activities (Know Your Customer, KYC).

[0004] Beyond the DeFi scenarios exemplified above, other blockchain practices also require identity verification for accounts within the blockchain system. Traditional KYC verification typically necessitates a single certification authority to centrally collect, store, and verify user identities off-chain, violating the fundamental principle of blockchain decentralization. Furthermore, traditional KYC verification directly marks or associates account-user identities on the blockchain, making it highly susceptible to malicious deductions based on the transparency of blockchain data, thus failing to protect user privacy. 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] Obtain the first transaction, which calls the verification contract and contains the 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 the first account address.

[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 is verified successfully, 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, in the contract state of the verification contract, record the identity authentication status corresponding to the first account address as a state of passed identity authentication.

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

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

[0012] The secret hash is sent to the first user along the corresponding Merck path in the certified Merck tree.

[0013] 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:

[0014] The first data provided by the first user is input into the first circuit, which is constructed based on a zero-knowledge proof framework. The first data includes at least a first Merck path as privacy input and first secret data, and a first account address as public input.

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

[0016] Generate a zero-knowledge proof, which includes a first account address, and the zero-knowledge proof is used to prove that a first root hash is calculated based on first secret data.

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

[0018] The method provided in the embodiments of this specification can complete account authentication in a blockchain system without disclosing any user privacy. Utilizing zero-knowledge proof technology, the blockchain only publicly discloses the root hash of the authentication Merck tree and the user's zero-knowledge proof. No third party can reverse engineer the user's entity information based on this, thus effectively protecting user privacy while meeting regulatory requirements. Attached Figure Description

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

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

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

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

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

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

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

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

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

[0028] 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 shared interest alliance to jointly maintain the operation of the blockchain.

[0029] 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 through transactions on the blockchain system. Smart contracts can be defined in the form of code.

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

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

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

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

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

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

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

[0037] Contract account: Stores the executed smart contract code and the values ​​of the state within the smart contract code. It can usually only be activated by an external account.

[0038] Externally owned account: A user's account, such as the account of the owner of financial assets.

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

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

[0041] Balance: The amount of financial assets held at this address.

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

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

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

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

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

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

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

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

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

[0051] 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 image. 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). 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.

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

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

[0054] 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).

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

[0056] In the financial sector, the real user identity verification process mentioned above (also referred to as identity authentication below) 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.

[0057] In related technologies, some attempts have been made to introduce the KYC process 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.

[0058] In view of this, the inventors have proposed a method for authenticating accounts in a blockchain system in the embodiments of this specification, aiming to achieve controllable compliance of accounts in the financial asset transfer process on the blockchain system. 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.

[0059] 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 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 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. Simultaneously, the 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.

[0060] 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, and include the first account address requiring authentication status verification in the public 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.

[0061] To verify the identity authentication status of the first user's account address in the blockchain system, the zero-knowledge proof and the first 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.

[0062] 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 verification passes, it checks whether the first hash is the same as the second hash stored in the contract state of the authentication contract in the blockchain system. If they are the same, corresponding to Figure ⑤, it can be proven that the user corresponding to the first account address (in this embodiment, the first user) has passed identity authentication, and the identity authentication status corresponding to the first account address can be recorded as passed. In short, the above verification process first confirms the correspondence between the first hash and the secret data by verifying the zero-knowledge proof; and further, by comparing the consistency between the first hash and the authentication Merkle root hash (i.e., the second hash) uploaded to the blockchain by the authentication authority, it proves whether the user to whom the secret data belongs has passed identity authentication at the authentication authority, thus ultimately determining the identity authentication status of the account address owner in the blockchain system. The overall verification process does not disclose the user's private secret data, nor does it disclose the privacy data information used by the user when performing identity authentication at the authentication authority. Therefore, the verification of the account identity authentication status can be completed in the blockchain system without disclosing any user privacy. It is understandable 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.

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

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

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

[0066] 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:

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

[0068] The identity authentication authority, acting as a trusted third party, is responsible for reviewing and verifying the authentication materials submitted by users and generating corresponding credentials for authenticated users. In practice, multiple identity authentication authorities can coexist. These authorities are typically maintained and audited by a list managed by a decentralized autonomous organization (DAO), and only identity authentication 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 authentication authority, to support the coexistence and verification of multi-source identity authentication data.

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

[0070] After receiving the authentication data of 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. Specifically, step S403 includes at least the following steps:

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

[0072] 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 verification 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 verification 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), verification of the legality of the verification 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).

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

[0074] 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 and stores the root hash corresponding to the root node of the authentication Merk tree in the blockchain system.

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

[0076] Finally, in step S4037, the identity authentication authority may send the secret hash to the first user via the corresponding Merck path in the authentication Merck tree.

[0077] 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, and can generate a zero-knowledge proof off-chain without revealing the original secret data, to prove that they possess the secret data required to construct the root hash of the certified Merck tree.

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

[0079] 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:

[0080] Step S501: Input the first data provided by the first user into the first circuit. The first circuit is constructed based on the zero-knowledge proof framework. The first data includes at least the first Merck path as a private input (also known as witness information) and the first secret data, and the first account address as a public input.

[0081] 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 privacy 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.

[0082] 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 the statement, while simultaneously being unable to obtain any information about that witness.

[0083] 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 as public input, 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.

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

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

[0086] The first circuit performs 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.

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

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

[0089] Next, in step S507, a zero-knowledge proof is generated, which includes a first account address. The zero-knowledge proof is used to prove that the first root hash is calculated based on the first secret data.

[0090] After reconstructing the first hash, the first circuit can further invoke a zero-knowledge proof generation algorithm to generate a corresponding zero-knowledge proof, with the first account address included as public input in the proof. This zero-knowledge proof can demonstrate 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.

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

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

[0093] After generating the zero-knowledge proof, the first user can use this proof to authenticate their account in the blockchain system. Specifically, the first user can send a first transaction to the blockchain system via their user device. This first transaction invokes a verification contract and includes first proof data, which at least includes the zero-knowledge proof and a first root hash. The verification contract verifies the zero-knowledge proof and, if the zero-knowledge proof passes verification, determines whether the first root hash is the same as a second root hash stored in the blockchain system. As mentioned earlier, the second root hash is uploaded by the identity authentication authority and is the root hash of the authentication Merkle tree. The authentication Merkle 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 matches the second root hash, it can be confirmed that the user corresponding to the first account address (i.e., the first user) has completed identity authentication, and the identity authentication status of the first account address on the chain is updated accordingly. The entire identity authentication process effectively avoids the leakage of sensitive information such as user secret data or the authentication Merkle tree Merkle path while ensuring the credibility of the conclusion, thus meeting compliance requirements and protecting privacy data.

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

[0095] Through the steps described above, after the first user's identity is verified by the identity verification authority, a zero-knowledge proof can be generated based on the Merck path obtained from the authority and the user's private secret data. The first user can then use this zero-knowledge proof to complete the identity verification process for their account within the blockchain system.

[0096] 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 6As shown, in this embodiment, the method is executed by a node of the blockchain system and includes at least the following steps:

[0097] 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 first secret data input by the first user. The public input of the zero-knowledge proof includes the first account address.

[0098] 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 input of the zero-knowledge proof includes the account address (first account address) in the blockchain system to be authenticated. The generation process of the first root hash and the zero-knowledge proof has been described above and will not be repeated here. After receiving the first transaction, the node can call the verification contract based on the first transaction to execute step S603, verify the zero-knowledge proof, and, if the verification is successful, determine the authentication status of the first account address by verifying the consistency between the first root hash in the first proof data and the authentication Merck tree root hash stored in the blockchain system. Specifically, it includes at least the following steps:

[0099] Step S6031: Verify the zero-knowledge proof based on the first root hash; and if the zero-knowledge proof verification passes, proceed to step S6033: Determine 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, which 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, proceed to step S6035: Record the identity authentication status corresponding to the first account address as a passed authentication status in the contract status of the verification contract.

[0100] The node executes the first transaction and invokes the verification contract. This contract uses a pre-built verification algorithm and corresponding verification key to verify the zero-knowledge proof, confirming its validity. This means the generator (prover) of the zero-knowledge proof possesses the secret data required to generate the first hash and the calculation process is correct. After the zero-knowledge proof is verified, the verification contract further compares 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. Therefore, it can be inferred that the user holding the corresponding secret data (the first secret data) has completed identity authentication with that authority. Thus, the verification contract updates the authentication status of the first account address to "passed" and records it in the contract state. The entire identity authentication process can be fully automated on the blockchain system, without relying on any centralized identity authentication authority and without touching any of the user's secret data or sensitive information. This ensures both privacy and security while achieving secure and reliable account authentication.

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

[0102] 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 within the blockchain system based on the institution identifier contained in the first proof data, thereby improving the retrieval efficiency of the second root hash.

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

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

[0105] 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 settlements. 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.

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

[0107] 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 7In 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 some application scenarios of financial assets, it is only necessary to verify the real user identity of the receiving account to form a complete compliance chain for the circulation of financial assets. 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.

[0108] Please refer to the appendix for further details. Figure 7 The 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.

[0109] 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-defined computing device or service (such as a decentralized oracle network, Chainlink Keeper service, etc.) can automatically send a transaction (i.e., a second transaction) 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.

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

[0111] During the freeze period, the first asset still belongs to 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 verification results of the identity authentication status. The above-mentioned process of calling the verification contract to verify the identity authentication status of the participants in the transaction, and updating the identity authentication status, can be found in the methods and procedures given in the preceding embodiments, and will not be repeated here.

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

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

[0114] It should be noted that when the financial asset is not a native financial asset, such as the financial assets that can be valued as described above (or other on-chain assets issued based on standards such as ERC-20 and ERC-721), its circulation relies on the corresponding management contract (such as the financial asset 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 amount of financial assets held by 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 the 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.

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

[0116] The above-described method for account authentication in a blockchain system can complete account authentication without disclosing any user privacy. Utilizing zero-knowledge proof technology, the blockchain only publicly discloses the root hash of the authentication Merkle tree and the user's zero-knowledge proof. No third party can reverse engineer the user's entity information and secret data, thus effectively protecting user privacy while meeting regulatory requirements. Furthermore, the account authentication process can be initiated by the user, allowing them to change their on-chain account address at low cost to participate in different transaction scenarios. This effectively prevents big data analysis and behavioral tracking based on a single account address, further enhancing account anonymity and blockchain transaction privacy.

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

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

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

[0120] 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 also 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 also 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.

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

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

[0123] 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 said 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.

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

[0125] 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 illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

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

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

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

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

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

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

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

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

[0134] 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: Obtain the first transaction, which calls the verification contract and contains the 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 the first account address. 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 is verified successfully, 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, in the contract state of the verification contract, record the identity authentication status corresponding to the first account address as a state of passed identity authentication.

2. 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.

3. The method according to claim 2, 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.

4. The method according to claim 1, wherein, The first proof data also includes an authorized address; before invoking the verification contract based on the first transaction, the method further includes: Check the verification contract address corresponding to the verification contract. If the verification contract address is the same as the authorization address, then execute the verification contract; otherwise, terminate the execution of the verification contract.

5. The method according to claim 1, wherein, The zero-knowledge proof is generated by a first user inputting first secret data and the Merk path of the first secret data in the authentication Merk tree to the zero-knowledge proof circuit, and the verification contract includes a verification algorithm corresponding to the zero-knowledge proof circuit.

6. The method according to claim 1, wherein, Before determining whether the first hash is the same as the second hash stored in the blockchain system, the method further includes: By executing the authentication contract called by the verification contract, the second root hash stored in the contract state of the authentication contract is obtained.

7. 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; Update the certified Merck tree and store the root hash corresponding to the root node of the certified Merck tree in the blockchain system; The secret hash is sent to the first user along the corresponding Merck path in the certified Merck tree.

8. A method for authenticating an account in a blockchain system, performed by a first user's user device, the method comprising: The first data provided by the first user is input into the first circuit, which is built based on a zero-knowledge proof framework. The first data includes at least a first Merck path as privacy input and a first secret data, and a first account address as public input. 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, and the zero-knowledge proof is used to prove that a first root hash is calculated based on first secret data.

9. The method according to claim 8, wherein, The method further includes: 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 and, if the zero-knowledge proof passes verification, 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 an identity authentication authority and is the root hash of a certified Merkle tree. The certified Merkle tree is constructed by the identity authentication authority based on the hash values ​​of the secret data of multiple authenticated users.

10. The method according to claim 8, wherein, The first data also includes the authentication root hash; The generation of zero-knowledge proofs includes: The zero-knowledge proof is generated if the first root hash is the same as the authentication root hash.

11. The method according to claim 8, wherein, The first circuit operates offline within the trusted environment of the first user's user equipment.

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