Blockchain-based transaction verification method and device, electronic equipment and readable medium

Abstract

The application relates to a blockchain-based transaction verification method. The method comprises the following steps: receiving a key update request, wherein the key update request comprises identification information and a target public key, the identification information is used for uniquely identifying a receiving node; updating a to-be-updated public key corresponding to the identification information into the target public key; sending a transaction request to a consensus node, wherein the transaction request comprises the identification information and verification information, the verification information is generated after being signed by a target private key corresponding to the target public key; receiving a public key query request sent by the consensus node, wherein the public key query request comprises the identification information; sending the target public key to the consensus node according to the public key query request, so that the consensus node verifies the verification information according to the target public key. When the private key corresponding to the public key is unavailable, the method can replace the public key with a new public key, thereby avoiding the loss of user assets and improving the availability of the blockchain system.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a blockchain-based transaction verification method, apparatus, electronic device, and readable medium. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Each data block in a blockchain contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and to generate the next block.

[0003] In related technologies, during blockchain transactions, the asset sender typically uses the asset recipient's publicly disclosed public key to encrypt the assets being traded. The asset recipient then uses their private key to decrypt the assets when they need to receive them, thus enabling them to use the received assets.

[0004] The private key information of the asset recipient is usually stored offline by the asset recipient. However, if the private key is lost or corrupted, rendering it unusable, the asset recipient will be unable to use the acquired assets, resulting in losses for the user and affecting the availability of the blockchain system. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a blockchain-based transaction verification method, apparatus, electronic device, and readable medium. When the private key corresponding to the public key becomes unavailable, the public key can be replaced with a new public key, and the private key corresponding to the new public key can be used to verify the transaction. Therefore, this avoids loss of user assets and improves the availability of the blockchain system.

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0007] According to one aspect of the embodiments of this application, a blockchain-based transaction verification method is provided, comprising:

[0008] Receive a key update request, which includes identification information and a target public key, wherein the identification information is used to uniquely identify the receiving node;

[0009] Update the public key to be updated corresponding to the identification information to the target public key;

[0010] A transaction request is sent to the consensus node, wherein the transaction request includes the identification information and verification information, and the verification information is generated by signing with the target private key corresponding to the target public key;

[0011] Receive a public key query request sent by the consensus node, wherein the public key query request contains the identification information;

[0012] The target public key is sent to the consensus node according to the public key query request, so that the consensus node can verify the verification information based on the target public key.

[0013] According to one aspect of the embodiments of this application, a blockchain-based transaction verification device is provided, comprising:

[0014] An update request receiving module is used to receive a key update request, which includes identification information and a target public key, wherein the identification information is used to uniquely identify the receiving node;

[0015] The public key update module is used to update the public key to be updated corresponding to the identification information to the target public key;

[0016] A transaction request sending module is used to send a transaction request to a consensus node, wherein the transaction request includes the identification information and verification information, and the verification information is generated by signing with the target private key corresponding to the target public key;

[0017] A query request receiving module is used to receive a public key query request sent by the consensus node, wherein the public key query request contains the identification information;

[0018] The public key sending module is used to send the target public key to the consensus node according to the public key query request, so that the consensus node can verify the verification information according to the target public key.

[0019] In some embodiments of this application, based on the above scheme, the key update request further includes an operator identity type, an operator signature, operator verification information, and an operator verification signature. The operator identity type is used to identify the identity of the initiator of the key update request, and the operator verification signature is obtained by signing the operator verification information based on the target private key; the public key update module includes:

[0020] The operator public key determination unit is used to determine the operator public key of the initiator of the key update request based on the identity type.

[0021] An identity verification unit is used to verify the identity of the operator's signature based on the operator's public key, and obtain the identity verification result.

[0022] A key verification unit is used to perform key verification based on the target public key, the operator verification information, and the operator verification signature, and obtain a key verification result.

[0023] The public key update unit is used to update the public key to be updated corresponding to the identification information to the target public key if both the identity verification result and the key verification indicate that the verification is successful.

[0024] In some embodiments of this application, based on the above scheme, the key update request further includes an administrator identifier and an operator public key determination unit, including:

[0025] The receiving node public key acquisition subunit is used to acquire the public key to be updated as the operator's public key if the identity type indicates that the initiator of the key update request is the receiving node.

[0026] The administrator public key acquisition subunit is used to acquire the administrator public key corresponding to the administrator identifier as the operator public key if the identity type indicates that the initiator of the key update request is an administrator node.

[0027] In some embodiments of this application, based on the above scheme, the identity verification unit includes:

[0028] The operator public key signing subunit is used to sign the key update request based on the operator public key to obtain an identity signing result;

[0029] The identity verification passed subunit is used to generate an identity verification result to indicate that the identity verification has passed if the identity signature result matches the operator's signature.

[0030] The identity verification failure subunit is used to generate an identity verification result to indicate identity verification failure if the identity signature result is inconsistent with the operator's signature.

[0031] In some embodiments of this application, based on the above scheme, the key verification unit includes:

[0032] The operator verification signature verification subunit verifies the operator verification signature based on the target public key and obtains the signature verification result;

[0033] The key verification passed subunit is used to generate a key verification result to indicate that the key verification has passed if the signature verification result is consistent with the operator verification information;

[0034] The key verification failure subunit is used to generate a key verification result to indicate key verification failure if the signature verification result is inconsistent with the operator verification information.

[0035] In some embodiments of this application, based on the above scheme, the blockchain-based transaction verification device further includes:

[0036] The management information update request receiving module is used to receive management information update requests. The management information update request includes a manager identity type, a manager identity signature, a newly added administrator identifier, a newly added administrator public key, manager verification information, and a manager verification signature. The manager identity type is used to identify the identity of the initiator of the management information update request. The manager verification signature is obtained by signing the manager verification information based on the newly added administrator private key corresponding to the newly added administrator public key.

[0037] The management public key determination module is used to determine the management public key of the initiator of the management information update request based on the manager's identity type.

[0038] The administrator identity verification module is used to verify the administrator's identity signature based on the administrator's public key and obtain the administrator verification result.

[0039] The key verification and identity verification module is used to perform key verification based on the newly added administrator public key, the administrator verification information, and the administrator verification signature to obtain the management information verification result.

[0040] The management information update module is used to update the management information corresponding to the identification information based on the newly added administrator identifier and the newly added administrator public key if both the administrator verification result and the management information verification result indicate that the verification has passed.

[0041] In some embodiments of this application, based on the above scheme, the blockchain-based transaction verification device further includes:

[0042] The information sending module is used to send the identification information and the public key to be updated to the service node, so that the service node stores the mapping relationship between the identification information and the public key to be updated, and the service node is used to obtain the public key to be updated according to the identification information;

[0043] A service address information receiving module is used to receive service address information sent by the service node, wherein the service address information is used to uniquely identify the service node.

[0044] The service address index update module is used to update the service address index of the blockchain according to the mapping relationship between the identification information and the service address information.

[0045] In some embodiments of this application, based on the above scheme, the transaction request sending module includes:

[0046] The historical transaction information acquisition unit is used to acquire historical transaction information corresponding to the identification information from the blockchain based on the identification information.

[0047] The historical transaction information signing unit is used to sign the historical transaction information according to the target private key to obtain the verification information;

[0048] Based on the identification information and the verification information, the transaction request is generated and sent to the consensus node.

[0049] According to one aspect of the embodiments of this application, a blockchain-based transaction verification method is provided, comprising:

[0050] Receive a transaction request, the transaction request containing identification information, transaction address information and verification information, the verification information being generated by signing with the target private key corresponding to the target public key;

[0051] The transaction address is verified based on the identification information and the transaction address information to obtain the address verification result.

[0052] Based on the identification information, obtain the target public key corresponding to the identification information from the service node;

[0053] A validity check is performed based on the target public key and the verification information to obtain a validity check result;

[0054] The transaction verification result is determined based on the address verification result and the legality verification result.

[0055] According to one aspect of the embodiments of this application, a blockchain-based transaction verification device is provided, characterized in that it includes:

[0056] A transaction request receiving module is used to receive a transaction request, which includes identification information, transaction address information and verification information, wherein the verification information is generated by signing with the target private key corresponding to the target public key.

[0057] The transaction address verification module is used to verify the transaction address based on the identification information and the transaction address information, and obtain the address verification result.

[0058] The target public key acquisition module is used to obtain the target public key corresponding to the identification information from the service node based on the identification information;

[0059] The legitimacy verification module is used to perform legitimacy verification based on the target public key and the verification information, and obtain the legitimacy verification result;

[0060] The transaction verification result module is used to determine the transaction verification result based on the address verification result and the legality verification.

[0061] In some embodiments of this application, based on the above scheme, the target public key acquisition module includes:

[0062] The service address information query unit is used to query service address information from the service address index of the blockchain based on the identification information. The address index table is used to store the mapping relationship between the identification information and the service address information.

[0063] The identification information sending unit is used to send the identification information to the service node corresponding to the service address information according to the service address information, so as to obtain the target public key corresponding to the identification information.

[0064] In some embodiments of this application, based on the above scheme, the transaction address verification module includes:

[0065] A hash calculation unit is used to perform hash calculation on the identification information to obtain a hash value;

[0066] The address verification unit is used to generate an address verification result to indicate that the address verification is successful if the hash value matches the transaction address information.

[0067] The address verification failure unit is used to generate an address verification result to indicate address verification failure if the hash value is inconsistent with the transaction address information.

[0068] In some embodiments of this application, based on the above scheme, the legality verification module includes:

[0069] A signature verification unit is used to verify the verification information based on the target public key to obtain a signature verification result;

[0070] The legitimacy verification unit is used to determine that the legitimacy verification is passed if the signature verification result is consistent with the historical transaction information corresponding to the identification information.

[0071] The legality verification failure unit is used to determine that the legality verification has failed if the transaction signature result is inconsistent with the historical transaction information corresponding to the identification information.

[0072] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute a blockchain-based transaction verification method as described above by executing the executable instructions.

[0073] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the blockchain-based transaction verification method as described above.

[0074] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain-based transaction verification method provided in the various optional implementations described above.

[0075] In the embodiments of this application, the public key to be updated is updated based on the identification information, and a transaction request is initiated using the updated public key to complete transaction verification. This scheme uses identification information instead of the public key hash value to identify transaction nodes. When the private key corresponding to the public key becomes unavailable, the public key can be replaced with a new public key, and the private key corresponding to the new public key can be used to verify the transaction and complete the transaction. Therefore, it can prevent user assets from being lost and improve the availability of the blockchain system.

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

[0077] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0078] In the attached diagram:

[0079] Figure 1 This is an optional structural diagram of the distributed system 100 provided in this embodiment of the invention applied to a blockchain system;

[0080] Figure 2 This is a schematic diagram of the block's composition structure in an embodiment of this application;

[0081] Figure 3 This is a schematic flowchart of a blockchain-based transaction verification method in the embodiments of this application;

[0082] Figure 4 This is a schematic flowchart of the key update process in an embodiment of this application;

[0083] Figure 5 This is a schematic flowchart illustrating the management information update request in an embodiment of this application;

[0084] Figure 6 This is a schematic flowchart illustrating the contract publishing and verification processes in the embodiments of this application;

[0085] Figure 7 A schematic block diagram illustrating the composition of a blockchain transaction verification device in an embodiment of this application is shown.

[0086] Figure 8 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0087] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0088] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0089] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0090] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0091] It should be understood that the transaction verification method provided in this application can be applied to blockchain systems. Blockchain is a ledger technology that is jointly maintained by multiple parties, uses cryptography to ensure secure transmission and access, and enables consistent data storage, tamper-proofing, and non-repudiation; it is also known as distributed ledger technology. A typical blockchain stores data in a block-chain structure.

[0092] This application can be applied to various blockchain implementations, including public, private, and consortium blockchains. Public blockchains lack centralized oversight from official organizations or management bodies and do not rely on fixed core servers for service provision. They operate according to blockchain rules, with all nodes joining following these rules, and transactions between nodes proceeding according to a consensus mechanism defined by those rules. Common public blockchain forms include virtual resources such as quantum mechanics. Private blockchains are established and owned by organizations or individuals, typically used within an organization or by a limited number of authorized users. Private blockchains usually restrict node permissions for modification, reading, and transactions, and may have several key nodes for consensus and record-keeping, while other nodes do not participate in record-keeping. Consortium blockchains are typically established by several organizations and jointly used and managed by them. Each participating organization in a consortium blockchain usually designates several nodes as consensus nodes, which collectively handle record-keeping, while transactions between other nodes are recorded by these consensus nodes.

[0093] This application proposes a blockchain-based transaction verification method. The system involved in this embodiment of the invention can be a distributed system formed by connecting a client and multiple nodes (any form of computing device in the network, such as a server or user terminal) through network communication.

[0094] Taking a distributed system as an example, see blockchain system. Figure 1 , Figure 1 This is an optional structural diagram of the distributed system 100 provided in this embodiment of the invention applied to a blockchain system. It consists of multiple nodes (any form of computing device in the network, such as servers or user terminals) and clients, forming a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In the distributed system, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0095] See Figure 1 The functions of each node in the blockchain system shown include:

[0096] 1) Routing: A basic function of nodes used to support communication between nodes.

[0097] In addition to routing capabilities, nodes can also have the following functions:

[0098] 2) Applications are deployed in the blockchain to implement specific business needs. They record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system. When other nodes successfully verify the source and integrity of the record data, they add the record data to a temporary block.

[0099] For example, the business logic implemented by the application includes:

[0100] 2.1) A wallet is used to provide the function of trading virtual resources, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system. After the other nodes successfully verify the transaction, they store the transaction record data in the temporary block of the blockchain as a response to acknowledge the validity of the transaction; of course, the wallet also supports querying the remaining virtual resources in the virtual resource address.

[0101] 2.2) Shared ledger, used to provide functions such as storage, query and modification of ledger data. It sends the record data of the operation on the ledger data to other nodes in the blockchain system. After the other nodes verify the validity, as a response to acknowledge the validity of the ledger data, they store the record data in a temporary block. They can also send confirmation to the node that initiated the operation.

[0102] 2.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented through code deployed on a shared ledger that executes when certain conditions are met. Based on actual business needs, the code is used to complete automated transactions, such as querying the logistics status of goods purchased by a buyer and transferring the buyer's virtual resources to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts for processing received information.

[0103] 3) A blockchain consists of a series of blocks that are sequentially generated. Once a new block is added to the blockchain, it will not be removed. The blocks contain the data submitted by the nodes in the blockchain system.

[0104] Distributed nodes include transaction nodes and consensus nodes. However, it should be understood that transaction nodes and consensus nodes are merely distinctions regarding the identity of nodes, not classifications of distributed nodes. A distributed node can have one or more identities, switch between different identities, or have different identities in different scenarios. For example, a node may act as a transaction node when conducting a transaction, but it can also act as a consensus node to verify and record the transactions of other nodes. It should be noted that... Figure 1 The number of distributed nodes shown is for illustrative purposes only; any number of distributed nodes can be deployed as needed.

[0105] In one embodiment of this application, distributed nodes can generate transaction information according to the transaction rules of the blockchain network and broadcast the transaction information within the blockchain network. Consensus nodes in the blockchain network verify the transaction upon receiving it and broadcast the verification result. Once the consensus nodes in the blockchain network reach a consensus on the transaction information according to the rules, they can record the transaction in the ledger and notify other network nodes in the blockchain network to update the recorded information.

[0106] Users can access any network node in the aforementioned blockchain through client devices and initiate transaction requests through that node. Each user has a wallet address within the blockchain network, typically associated with the public key of a public-private key pair. The user needs to use their private key to unlock the assets corresponding to their wallet address in order to initiate a transaction for consumption. During the transaction, an unlocking script and a locking script are generated. The unlocking script unlocks assets previously transferred to the user's wallet address, while the locking script indicates a transaction to another user's wallet address and locks the transferred assets. When the recipient of the assets wants to conduct other transactions, they use their private key to unlock the assets in their wallet address to complete the transaction. It should be noted that the client is deployed on a terminal device, which includes, but is not limited to, in-vehicle terminals, tablets, laptops, PDAs, mobile phones, and personal computers (PCs).

[0107] Please see Figure 2 , Figure 2 This is a schematic diagram illustrating the structural composition of a block in this embodiment of the application. As shown in the figure, a blockchain consists of multiple blocks. A block is a data organization unit in the blockchain network, linked together by a linked list. A block includes a block header and a block body. The block header includes the hash value of the previous block, the timestamp of the current block, the block height, and other information (e.g., the Merkle root of the block body, the difficulty target, and the random value). The block body includes transaction information, such as "A transfers 50 virtual resources to B." Each transaction corresponds to a hash value, which uniquely and accurately identifies a specific transaction. A transaction may include the address of the target, the amount, the hash value of the referencing transaction, the unlock script, and the lock script.

[0108] See Figure 2 , Figure 2This is an optional schematic diagram of the block structure provided in this embodiment of the invention. Each block includes the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected through their hash values ​​to form a blockchain. Additionally, the block may include information such as a timestamp when it was generated. A blockchain is essentially a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains relevant information used to verify the validity of the information (anti-counterfeiting) and to generate the next block.

[0109] Based on the above introduction, the blockchain-based transaction verification method of this application will be described below. This blockchain-based transaction verification method can be implemented using computer equipment; please refer to [link / reference needed]. Figure 3 , Figure 3 This is a schematic flowchart illustrating the blockchain-based transaction verification method in this application embodiment. The blockchain-based transaction verification method in this application embodiment may include the following steps:

[0110] Step S301: Receive a key update request. The key update request includes identification information and a target public key, wherein the identification information is used to uniquely identify the receiving node.

[0111] In this embodiment, the receiving node receives a key update request. The receiving node is the blockchain account owned by the user; when a user accesses a specific network node device, that device can be considered a receiving node. Identification information is used to uniquely identify the receiving node, and it typically uses highly readable and easy-to-remember information, such as the user's mobile phone number or email address. The key update request is usually initiated by the user when they discover that the private key information corresponding to their blockchain account is unavailable, in order to update the encrypted information corresponding to the blockchain account. Specifically, the user needs to generate a new public-private key pair and initiate a key update request based on the public key and their blockchain account's identification information.

[0112] Step S302: Update the public key to be updated corresponding to the identification information to the target public key.

[0113] The receiving node updates the public key to be updated corresponding to the identification information to the target public key. The public key to be updated is the public key previously used by the user's blockchain account, and the corresponding private key is the user's lost private key. Specifically, this update process can be executed according to a smart contract issued by the asset recipient (i.e., the user). A smart contract is a computer protocol designed to disseminate, verify, or execute contracts in an informational manner. Smart contracts allow for trusted transactions without a third party; these transactions are traceable and irreversible. This smart contract is used to manage the mapping relationship between identification information and public keys. The receiving node replaces the public key to be updated corresponding to the identification information with the newly generated target public key according to the smart contract. In some embodiments, before replacing the public key, the key update request also needs to be verified to confirm that the initiator of the request has the corresponding authority. The verification process typically includes verifying the identity of the initiator and verifying the correctness of the target public key.

[0114] Step S303: Send a transaction request to the consensus node, wherein the transaction request includes the identification information and verification information, and the verification information is generated by signing with the target private key corresponding to the target public key.

[0115] The receiving node sends a transaction request to the consensus node. The transaction request can be initiated by the user or automatically by the client. The transaction request is used to transfer assets to the blockchain account of the transaction target. Understandably, the transaction request will also contain information associated with the blockchain account of the transaction target; in this embodiment, this is the identification information of the blockchain account of the transaction target. For example, if A wants to trade 5 virtual resources to B, the transaction information will include the identification information of B's ​​blockchain account, such as B's mobile phone number. During the generation of the transaction request, the receiving node uses the target's private key provided by the user to sign the transaction. The transaction signing process typically involves running a signature algorithm on several fields in the transaction according to a signature protocol to obtain a signature result, which is the verification information. During the consensus process, the consensus node uses the verification information to confirm that the initiator of the transaction is indeed the owner of the asset-output account.

[0116] A transaction request typically includes two parts: an unlock script and a lock script. The unlock script usually includes the aforementioned identification and verification information to facilitate the transfer of assets from other accounts to the user's blockchain account. The lock script is used to output its assets to the target account in this transaction. Therefore, the lock script contains an encrypted address generated based on the target account's identification information and a series of opcodes, which the target account uses to unlock and use the assets obtained in this transaction during subsequent transactions.

[0117] Step S304: Receive the public key query request sent by the consensus node, wherein the public key query request contains the identification information.

[0118] The receiving node receives a public key query request from the consensus node, which contains the identification information. Upon receiving a transaction request, the consensus node performs a verification process. During this verification, the consensus node obtains the address of the query service used to query the public key based on the identification information in the transaction request. This public key query function can specifically be part of the smart contract issued by the asset recipient (i.e., the user) mentioned above. The mapping between identification information and smart contract addresses can be stored in the blockchain or other storage space. The consensus node then queries the smart contract address corresponding to the identification information by accessing the blockchain or storage space. Based on the queried address, the consensus node sends a public key query request to obtain the public key required for verification. It is understood that the service used to receive public key query requests can be a separate service independent of the receiving node and executed by a separate server.

[0119] Step S305: Send the target public key to the consensus node according to the public key query request, so that the consensus node can verify the verification information according to the target public key.

[0120] The receiving node retrieves the target public key corresponding to the identifier information based on the public key query request and sends the target public key to the consensus node. After obtaining the target public key, the consensus node verifies the received transaction information based on the target public key. If the verification passes and consensus is reached among the consensus nodes, the transaction is recorded in the blockchain; otherwise, the transaction fails.

[0121] In the embodiments of this application, the public key to be updated is updated based on the identification information, and a transaction request is initiated using the updated public key to complete transaction verification. This scheme uses identification information instead of the public key hash value to identify transaction nodes. When the private key corresponding to the public key becomes unavailable, the public key can be replaced with a new public key, and the private key corresponding to the new public key can be used to verify the transaction and complete the transaction. Therefore, it can prevent user assets from being lost and improve the availability of the blockchain system.

[0122] The overall process of key update in this application is described below. For ease of explanation, please refer to [link to relevant documentation]. Figure 4 , Figure 4This is a schematic flowchart illustrating the key update process in this embodiment. Specifically, firstly, in step 401, the identity type of the initiator of the key update request needs to be determined. Depending on the identity type, in step 402, the key update request is signed using the public key of the contract publisher; or in steps 403 and 404, the administrator's public key corresponding to the administrator identifier is obtained and used to sign the key update request. In step 405, it is verified whether the generated signature matches the operator signature carried in the key update request. If they do not match, an error is reported directly, and the process ends. If they match, in step 406, the random number (i.e., operator verification information) carried in the key update request is signed using the target public key, and then in step 407, it is determined whether the generated signature matches the operator verification signature carried in the key update request. If they do not match, an error is reported directly, and the process ends. If they match, in step 408, the public key to be updated is replaced with the target public key to complete the key update process.

[0123] In some embodiments of this application, based on the above embodiments, the key update request further includes an operator identity type, an operator signature, operator verification information, and an operator verification signature. The operator identity type is used to identify the identity of the initiator of the key update request, and the operator verification signature is obtained by signing the operator verification information based on the target private key. Step S302 above, updating the public key to be updated corresponding to the identification information to the target public key, may include the following steps:

[0124] Based on the identity type, determine the operator's public key of the initiator of the key update request;

[0125] Based on the operator's public key, the operator's signature is verified to obtain the identity verification result;

[0126] Key verification is performed based on the target public key, the operator verification information, and the operator verification signature to obtain the key verification result.

[0127] If both the identity verification result and the key verification result indicate that the verification is successful, then the public key to be updated corresponding to the identification information will be updated to the target public key.

[0128] In this embodiment, the key update request also includes the operator identity type, operator signature, operator verification information, and operator verification signature. According to the smart contract published by the asset recipient (i.e., the user), the initiator of the key update request includes two identities: the contract publisher, i.e., the asset recipient, who is the user possessing the private key, and a pre-agreed administrator. The administrator also possesses an administrator identifier and corresponding public and private keys. The mapping relationship between the administrator identifier and the administrator public key can be stored and obtained through the smart contract, typically stored in the blockchain or on the device corresponding to the smart contract address. Therefore, the key update request includes the operator identity type, which is usually the contract publisher, administrator, or others, where other identities do not have the authority to update the key. The operator signature is obtained by the initiator of the key update request using their private key. The operator verification signature is obtained by signing the operator verification information based on the target private key. The operator verification information and operator verification signature are mainly used to verify the newly generated public and private keys provided. The operator verification information can use random numbers or other preset information.

[0129] The receiving node determines whether the initiator of the key update request is the contract publisher or an administrator based on the identity type, and obtains the corresponding operator's public key. Based on the operator's public key, the receiving node verifies the operator's signature to obtain the identity verification result. The purpose of identity verification is to confirm that the account initiating the key update request has the correct permissions. Specifically, the operator's signature is the result of signing based on a private key, which, depending on the operator's identity, can be the contract publisher's private key or the administrator's private key. By signing the same content using the corresponding operator's public key (e.g., signing the key update request according to the same signing rules), if the signature result matches the operator's signature, it can be confirmed that the account initiating the key update request has the correct permissions and can perform the public key update.

[0130] The receiving node also needs to verify the correctness of the public key contained in the key update request to prevent tampering. Specifically, the receiving node performs key verification based on the target public key, operator verification information, and operator verification signature to obtain the key verification result. The operator verification signature is obtained by signing the operator verification information using the target private key. The receiving node signs the operator verification information using the target public key to obtain a signature result. If this signature result matches the operator verification signature, it indicates that the public key in the key update request is correct.

[0131] If both the identity verification and key verification results indicate that the verification passed, the key update process is considered legitimate, and the receiving node updates the public key to be updated corresponding to the identification information to the target public key. In subsequent processes, when other nodes query the receiving node for the public key based on the identification information, the receiving node will return the target public key for use in blockchain operations such as verification and transactions.

[0132] In the embodiments of this application, the identity of the operator initiating the key update request and the content of the request are verified to ensure that the key update request is initiated by an authorized user and that the content has not been tampered with, thereby ensuring the correctness and security of the key update process.

[0133] In some embodiments of this application, based on the above embodiments, the key update request further includes an administrator identifier; the above steps, determining the operator's public key of the initiator of the key update request according to the identity type, may include the following steps:

[0134] If the identity type indicates that the initiator of the key update request is the receiving node, then the public key to be updated is obtained as the operator's public key;

[0135] If the identity type indicates that the initiator of the key update request is an administrator node, then the administrator public key corresponding to the administrator identifier is obtained as the operator public key.

[0136] In this embodiment, the identity type in the key update request includes two types: receiving node and administrator node. The receiving node is the node connected to by the owner of the account targeted by the key update request. When the identity type in the key update request is [identity type missing], it can be understood that the key update request is initiated by the asset recipient, i.e., the contract issuer. In such cases, it is usually because the original private key is still usable, but the asset owner updates the public key for security reasons (e.g., suspecting a private key leak). Therefore, if the identity type indicates that the initiator of the key update request is a receiving node, the public key to be updated is obtained as the operator's public key. For the identification information of an account, its corresponding operator's public key is usually unique, so the operator's public key can be obtained directly.

[0137] Administrator nodes are nodes pre-defined in the smart contract as having the authority to update the public keys of other nodes. Therefore, when the identity type in a key update request is "administrator node," it can be understood that the key update request was initiated by an administrator. In such cases, the original private key is usually unusable, for example, it has been lost or the data is corrupted. The user entrusts the administrator to update the public key corresponding to their account through an external means to facilitate transactions. Therefore, if the identity type indicates that the initiator of the key update request is an administrator node, the administrator public key corresponding to the administrator identifier is obtained as the operator's public key. Specifically, the administrator public key can be obtained according to the smart contract published by the asset recipient based on the administrator identifier. According to the smart contract, the receiving node maintains the correspondence between administrator identifiers and administrator public keys. The receiving node can maintain multiple administrator identifiers and their corresponding administrator public keys, and can query the corresponding administrator public key through the administrator identifier.

[0138] It is understandable that the two identities mentioned above are those with the authority to update keys. Nodes in the blockchain can also have other identities, such as transaction nodes, consensus nodes, etc. Key update requests initiated by such identities will fail.

[0139] In the embodiments of this application, key updates can be performed through two channels: the asset recipient and the administrator. This allows users to update their public keys themselves, increasing the flexibility of the update process.

[0140] In some embodiments of this application, based on the above embodiments, the above steps, which involve verifying the operator's signature based on the operator's public key to obtain the identity verification result, may include the following steps:

[0141] The key update request is signed using the operator's public key to obtain the identity signature result;

[0142] If the identity signature result matches the operator's signature, an identity verification result is generated to indicate that the identity verification has passed;

[0143] If the identity signature result does not match the operator's signature, an identity verification result is generated to indicate that the identity verification failed.

[0144] Specifically, the operator's signature is the result of signing using the private key. Therefore, the receiving node can sign the key update request using the operator's public key. Specifically, by performing a signature operation based on the operator's signature and public key, an identity signature result can be obtained. Specifically, the signature calculation can be performed by extracting preset fields from the key update request and encrypting them. If the identity signature result matches the operator's signature, it indicates that the initiator of the key update request is legitimate, and an identity verification result is generated to indicate that the identity verification has passed. If the identity signature result does not match the operator's signature, it indicates that the initiator of the key update request is illegitimate, and an identity verification result is generated to indicate that the identity verification has failed.

[0145] It is understandable that the operator's public key and the private key used to obtain the operator's signature are a corresponding public and private key pair. Therefore, the verification process can also adopt a decoding method, that is, using the operator's public key to decode the operator's signature, and then comparing the decoded content with the information in the key update request. If the decoded content matches the information in the key update request, the authentication is successful; if they do not match, the authentication fails.

[0146] In this embodiment, the operator's identity is verified using the operator's public key and operator signature. Since the operator signature is generated based on the private key, identity verification can ensure that the initiator of the key update request has the authority to update the public key, thereby improving the system's security.

[0147] In some embodiments of this application, based on the above embodiments, the above steps, which involve key verification based on the target public key, operator verification information, and operator verification signature to obtain the key verification result, may include the following steps:

[0148] Based on the target public key, the operator's signature is verified to obtain the signature verification result;

[0149] If the signature verification result matches the operator's verification information, a key verification result is generated to indicate that the key verification has passed.

[0150] If the signature verification result is inconsistent with the operator's verification information, a key verification result is generated to indicate that the key verification failed.

[0151] Specifically, the operator verification information and operator verification signature are used to verify the correctness of the target public key. The operator verification information can be a random number or other specified information. The random number is set by the initiator of the key update request and is signed by the initiator using the target private key to obtain the operator verification signature. During verification, the operating node performs a signature operation on the operator verification signature based on the target public key to obtain a signature verification result. Depending on the specific implementation, this signature operation can also be a decoding operation. The signature verification result is compared with the operator verification information. If the signature verification result matches the operator verification information, it means that the target public key matches the private key used to generate the operator verification signature, i.e., it is a correct public key. Therefore, a key verification result is generated to indicate that the key verification passed. If the signature verification result does not match the operator verification information, it means that the target public key cannot correctly perform the operator verification signature. In this case, a key verification result is generated to indicate that the key verification failed.

[0152] In this embodiment, the target public key is verified by operator verification information and operator verification signature, thereby ensuring that the target public key matches the target private key owned by the initiator. This ensures the accuracy of the updated public key, prevents third parties from replacing the target public key to attack the system, and improves system security.

[0153] The overall process of key update in this application is described below. For ease of explanation, please refer to [link to relevant documentation]. Figure 5 , Figure 5 This is a schematic flowchart illustrating the management information update request in this embodiment. Specifically, firstly, in step 501, it is necessary to determine the identity type of the initiator of the management information update request. Depending on the identity type, in step 502, the management information update request is signed using the public key of the contract publisher; or in steps 503 and 504, the administrator's public key corresponding to the administrator identifier is obtained and used to sign the management information update request. In step 505, it is verified whether the generated signature matches the administrator identity signature carried in the management information update request. If they do not match, an error is reported directly, and the process ends. If they match, in step 506, the random number (i.e., administrator verification information) carried in the management information update request is signed using the newly added administrator public key, and then in step 507, it is determined whether the generated signature matches the administrator verification signature carried in the management information update request. If they do not match, an error is reported directly, and the process ends. If they match, in step 508, the newly added administrator identifier and the newly added administrator public key are added to the administrator list to complete the management information update process.

[0154] In some embodiments of this application, based on the above embodiments, the method of this application may further include the following steps:

[0155] Receive management information update request. The management information update request includes administrator identity type, administrator identity signature, new administrator identifier, new administrator public key, administrator verification information and administrator verification signature. Among them, the administrator identity type is used to identify the identity of the initiator of the management information update request, and the administrator verification signature is obtained by signing the administrator verification information with the new administrator private key corresponding to the new administrator public key.

[0156] Based on the administrator's identity type, determine the administrator's public key of the party initiating the management information update request;

[0157] Based on the administrator's public key, the administrator's identity signature is verified to obtain the administrator's verification result;

[0158] The key verification is performed based on the newly added administrator public key, administrator verification information, and administrator verification signature to obtain the management information verification result.

[0159] If both the administrator verification result and the management information verification result indicate that the verification has passed, then the management information corresponding to the identification information will be updated based on the newly added administrator identifier and the newly added administrator public key.

[0160] Specifically, in this embodiment, the management information corresponding to the identification information is updated according to the management information update request. The management information stores the administrator identifier with update authority over the public key of the identification information, as well as the corresponding administrator public key. The management information update request includes administrator identity type, administrator identity signature, newly added administrator identifier, newly added administrator public key, administrator verification information, and administrator verification signature. The administrator identity type serves the same purpose as the operator identity type described above, also representing the contract publisher and administrator. The administrator verification information and administrator verification signature are used to verify whether the newly added administrator public key is correct. The administrator verification information is typically a random number or other preset information, while the administrator verification signature is obtained by signing the administrator verification information using the newly added administrator private key corresponding to the newly added administrator public key. Compared to the key update request, the main difference in the management information update request is that it includes a newly added administrator identifier to represent the newly added administrator.

[0161] It is understandable that the process of obtaining the administrator's public key, verifying the administrator's identity, and verifying the management key is the same as the method described above for the key update request. If both the administrator verification result and the management information verification result indicate that the verification has passed, then the management information corresponding to the identification information is updated based on the newly added administrator identifier and the newly added administrator public key.

[0162] It should be understood that management information update requests can also update the keys corresponding to existing administrator identifiers, simply by replacing the new administrator identifier with the existing one.

[0163] In this embodiment, administrators are managed through management information update requests, thereby maintaining users with key modification permissions and allowing trusted users other than the contract publisher to update keys. This ensures the reliability of the update process by utilizing trusted administrators to update keys in the event that the contract publisher's private key is lost.

[0164] In some embodiments of this application, based on the above embodiments, the method of this application may further include the following steps:

[0165] Send identification information and the public key to be updated to the service node so that the service node can store the mapping relationship between the identification information and the public key to be updated. The service node can then use the identification information to obtain the public key to be updated.

[0166] Receive service address information sent by the service node; the service address information is used to uniquely identify the service node.

[0167] Update the blockchain's service address index based on the mapping relationship between identification information and service address information.

[0168] In this embodiment, the node used to execute the smart contract published by the resource recipient is a service node. However, this distinction is only a logical functional division; in reality, the service node can run on the same physical device as the resource recipient's receiving node, or it can run on a different physical device.

[0169] The operating node sends identification information and the public key to be updated to the service node, enabling the service node to store the mapping relationship between the identification information and the public key to be updated. Specifically, the service node generates a smart contract based on the identification information and the public key to be updated. This smart contract includes the correspondence between the identification information and the public key to be updated, a list of administrators corresponding to the identification information, a function to query the public key based on the identification information, a function to update the public key corresponding to the identification information, and a function to update the administrator list. After generating the smart contract, the service node sends the service address information of the smart contract to the operating node. The service address information is used to obtain the public key to be updated based on the identification information. Specifically, all the above functions provided by the smart contract are accessed through this service address information. After receiving the service address information, the operating node updates the service address index in the blockchain. The service address index stores the mapping relationship between various identification information and service address information in the blockchain. During the consensus process of transactions, the consensus node retrieves the service address information from the service address index based on the identification information, and then queries the public key based on the service address information to facilitate the consensus verification process.

[0170] In the scheme of this application, the service address information is centrally stored in the blockchain, so that other nodes can query the corresponding public key information according to the identification information when needed. This avoids the performance bottleneck caused by storing the service address information on a fixed server and the risk of transaction failure due to service address index corruption, thereby improving the robustness of the system.

[0171] In some embodiments of this application, based on the above embodiments, step S303, sending a transaction request to the consensus node, may include the following steps:

[0172] Based on the identification information, retrieve the historical transaction information corresponding to the identification information from the blockchain;

[0173] Based on the target private key, the historical transaction information is signed to obtain the verification information;

[0174] Based on the identification and verification information, a transaction request is generated and sent to the consensus node.

[0175] Specifically, based on the identification information, the historical transaction information corresponding to the identification information is retrieved from the blockchain. This historical transaction information refers to the transaction information of previously completed transactions where the recipient was the account corresponding to the identification information. For example, in previous transactions, three users, B, C, and D, transferred virtual resources to user A. Based on user A's identification information, the transaction information of users B, C, and D can be obtained. Each of these three transactions will generate a locking script to lock the funds. User A then needs to provide three corresponding unlocking scripts to unlock these funds for use. It can be understood that if user A only needs the amounts transferred by users B and C for transactions, then only the unlocking scripts for transactions with users B and C can be provided, without providing the unlocking script for unlocking user D's transaction.

[0176] The receiving node signs historical transaction information using the target private key to obtain verification information. The signing process follows a signature algorithm; specifically, it can sign transaction identifiers involved in the historical transaction information, which uniquely identify a transaction. Based on the identification and verification information, a transaction request is generated and sent to the consensus node. It's understood that in a blockchain, a typical transaction usually requires an unlocking script to unlock the input content and a locking script to specify the input content. In this embodiment, an unlocking script for the input transaction can be generated based on the target private key and verification information. Furthermore, encrypted calculations can be performed based on the target identification information of the transaction recipient to obtain the transaction address information. Specifically, the target identification information of the transaction recipient can be provided by the user. The specific method of encrypted calculation can employ encryption algorithms such as hash algorithms. For example, if the identification information is a mobile phone number, a hash calculation is performed on the mobile phone number, and the result is the transaction address information. A locking script for the output transaction can be generated based on the transaction address information. It is understandable that the output transaction will also include other content, such as the amount transferred, a series of opcodes, and other information used for the operation and calculation of the blockchain. Such information can be adjusted according to the content of relevant technologies, and this article does not limit it.

[0177] In this embodiment, when generating a transaction request, transaction address information is generated based on the identification information, so that the identification information can be used to conduct transactions in subsequent transactions. By unlocking the transaction address with the public key, the identification information can be set to content with specific meaning, so as to facilitate memorization and improve the readability of transaction information.

[0178] The following describes another embodiment of the blockchain-based transaction verification method in this application. This blockchain-based transaction verification method can be executed by a computer device, specifically by the computer device corresponding to the consensus node in the blockchain. The blockchain-based transaction verification method in this embodiment may include the following steps:

[0179] Receive a transaction request, which contains identification information, transaction address information, and verification information. The verification information is generated by signing the target private key corresponding to the target public key.

[0180] The transaction address is verified based on the identification information and the transaction address information to obtain the address verification result.

[0181] Based on the identification information, obtain the target public key corresponding to the identification information from the service node;

[0182] The legitimacy is verified based on the target public key and the verification information to obtain the legitimacy verification result;

[0183] The transaction verification result is determined based on the address verification result and the legality check.

[0184] Specifically, the consensus node receives a transaction request, which includes identification information, transaction address information, and verification information. The verification information is generated by signing the transaction using the target private key corresponding to the target public key. The identification and verification information included in the request correspond to the content of the unlock script, while the transaction address information corresponds to the content of the lock script.

[0185] The consensus nodes verify the transaction address based on the identification information and the transaction address information, obtaining the address verification result. The transaction address information is the encrypted transaction address information from historical transactions involving transfers to the user corresponding to the identification information. This transaction address information is generated based on the identification information. The address verification result indicates whether the current identification information is the transfer target of the transaction that the transaction request aims to unlock.

[0186] The consensus node obtains the target public key corresponding to the identification information from the service node. Specifically, the consensus node can query the target public key corresponding to the identification information through the smart contract published by the service node. A legitimacy verification is performed based on the target public key and the verification information to obtain the legitimacy verification result. The legitimacy transaction is used to verify the correspondence between the target public key and the target private key used to encrypt the verification information.

[0187] The transaction verification result is determined based on the address verification result and the validity check. The transaction verification result is successful if both the address verification result and the validity check pass. The transaction verification result is unsuccessful if either the address verification result or the validity check fails.

[0188] In a blockchain, according to consensus rules, when the verification by a consensus node meets the conditions stipulated in the consensus rules, the transaction is considered successful, and the consensus node can record the transaction information in the blockchain.

[0189] In the embodiments of this application, the consensus node queries the target public key based on the identification information to perform corresponding verification operations, thereby ensuring that the identification information can be used to conduct blockchain transactions and improving the feasibility of the solution.

[0190] The contract publishing and verification processes in this application embodiment are described in general below. Please refer to... Figure 6 , Figure 6This is a schematic flowchart illustrating the contract publishing and verification processes in this embodiment. As shown in step 6, the asset recipient generates a smart contract in step 611. The smart contract includes a mapping between identification information and public keys, an administrator list, a public key query service, a public key update service, and an administrator update service. In step 612, the smart contract is published to the blockchain, and in step 613, the identification information and smart contract address are updated in the service address index. During the consensus process, the consensus node verifies whether the identification information in the unlocking script matches the transaction address information in the locking script in step 621. Then, in step 622, it queries the service address information based on the service address index. In step 623, the consensus node uses the service address information to query the public key corresponding to the identification information. Then, in step 624, the consensus node signs the transaction based on the public key, compares the signature result with the signature in the unlocking script, and determines the transaction verification result based on the comparison result.

[0191] In some embodiments of this application, based on the above embodiments, the above steps, which involve verifying the transaction address based on the identification information and the transaction address information to obtain the address verification result, may include the following steps:

[0192] Based on the identification information, the service address information is queried from the service address index of the blockchain. The address index table is used to store the mapping relationship between the identification information and the service address information.

[0193] Based on the service address information, send identification information to the service node corresponding to the service address information in order to obtain the target public key corresponding to the identification information.

[0194] Specifically, the address index table stores the mapping relationship between identification information and service address information. Consensus nodes query the service address information from the blockchain's service address index based on the identification information. Each service address corresponds to a service node, which contains a smart contract published by the contract publisher to query the target public key corresponding to the identification information. Therefore, the consensus node sends the identification information to the corresponding service node based on the service address information. The service node then obtains the corresponding target public key based on the identification information and sends it to the consensus node.

[0195] In the embodiments of this application, service address information is queried through a service address index, and the target public key is then retrieved based on the service address information. Since the service address index is stored in the blockchain, it prevents the information in the service address index from being tampered with, thus avoiding interference with the public key query process and improving system stability.

[0196] In some embodiments of this application, based on the above embodiments, the above steps, which involve verifying the transaction address based on the identification information and the transaction address information to obtain the address verification result, may include the following steps:

[0197] The identification information is hashed to obtain a hash value;

[0198] If the hash value matches the transaction address information, an address verification result is generated to indicate that the address verification has passed;

[0199] If the hash value does not match the transaction address information, an address verification result is generated to indicate that the address verification failed.

[0200] Specifically, the transaction address information is obtained by hashing the asset transferor in historical transactions based on identification information. During address verification, the consensus node hashes the identification information to obtain a hash value. This hash value is then compared with the transaction address information. If the hash value matches the transaction address information, the account corresponding to the identification information is the account indicated by the transaction address information, and an address verification result is generated to indicate that the address verification passed. If the hash value does not match the transaction address information, the account corresponding to the identification information is not the account indicated by the transaction address information, and the user cannot use the assets in the transaction; therefore, an address verification result is generated to indicate that the address verification failed.

[0201] In the embodiments of this application, specific implementation methods for address verification are provided to improve the feasibility of the solution.

[0202] In some embodiments of this application, based on the above embodiments, the above steps, which involve performing a legitimacy verification based on the target public key and verification information to obtain a legitimacy verification result, may include the following steps:

[0203] Based on the target public key, the verification information is verified to obtain the signature verification result;

[0204] If the signature verification result matches the historical transaction information corresponding to the identification information, then the legality verification is deemed successful.

[0205] If the transaction signature result is inconsistent with the historical transaction information corresponding to the identification information, the legality verification is deemed to have failed.

[0206] Specifically, the verification information is encrypted using a private key. Consensus nodes can perform signature verification on the verification information based on the target public key, thus obtaining a signature verification result. This signature verification result is actually the historical transaction information obtained during encryption. The signature verification result is compared with the historical transaction information corresponding to the identification information, where the historical transaction information corresponding to the identification information is the historical transaction referenced in the current transaction request. If the signature verification result matches the historical transaction information corresponding to the identification information, it indicates that the user providing the verification information is the legitimate recipient of the assets and can unlock the assets in the transaction; therefore, the legitimacy verification is successful. If the transaction signature result does not match the historical transaction information corresponding to the identification information, it indicates that the user providing the verification information is not the legitimate recipient of the assets and cannot unlock the assets in the transaction; therefore, the legitimacy verification fails.

[0207] In the embodiments of this application, specific implementation methods for signature verification are provided to improve the feasibility of the solution.

[0208] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0209] The following describes the implementation of the apparatus of this application, which can be used to execute the blockchain transaction verification method in the above embodiments of this application. Figure 7 A schematic block diagram illustrating the composition of a blockchain transaction verification device according to an embodiment of this application is shown. Figure 7 As shown, the blockchain-based transaction verification device 700 mainly includes:

[0210] The update request receiving module 710 is used to receive a key update request, which includes identification information and a target public key, wherein the identification information is used to uniquely identify the receiving node;

[0211] The public key update module 720 is used to update the public key to be updated corresponding to the identification information to the target public key;

[0212] The transaction request sending module 730 is used to send a transaction request to the consensus node, wherein the transaction request includes the identification information and the verification information, and the verification information is generated by signing with the target private key corresponding to the target public key;

[0213] The query request receiving module 740 is used to receive the public key query request sent by the consensus node, wherein the public key query request includes the identification information;

[0214] The public key sending module 750 is used to send the target public key to the consensus node according to the public key query request, so that the consensus node can verify the verification information according to the target public key.

[0215] In some embodiments of this application, based on the above scheme, the key update request further includes an operator identity type, an operator signature, operator verification information, and an operator verification signature. The operator identity type is used to identify the identity of the initiator of the key update request, and the operator verification signature is obtained by signing the operator verification information based on the target private key; the public key update module 720 includes:

[0216] The operator public key determination unit is used to determine the operator public key of the initiator of the key update request based on the identity type.

[0217] An identity verification unit is used to verify the identity of the operator's signature based on the operator's public key, and obtain the identity verification result.

[0218] A key verification unit is used to perform key verification based on the target public key, the operator verification information, and the operator verification signature, and obtain a key verification result.

[0219] The public key update unit is used to update the public key to be updated corresponding to the identification information to the target public key if both the identity verification result and the key verification indicate that the verification is successful.

[0220] In some embodiments of this application, based on the above scheme, the key update request further includes an administrator identifier and an operator public key determination unit, including:

[0221] The receiving node public key acquisition subunit is used to acquire the public key to be updated as the operator's public key if the identity type indicates that the initiator of the key update request is the receiving node.

[0222] The administrator public key acquisition subunit is used to acquire the administrator public key corresponding to the administrator identifier as the operator public key if the identity type indicates that the initiator of the key update request is an administrator node.

[0223] In some embodiments of this application, based on the above scheme, the identity verification unit includes:

[0224] The operator public key signing subunit is used to sign the key update request based on the operator public key to obtain an identity signing result;

[0225] The identity verification passed subunit is used to generate an identity verification result to indicate that the identity verification has passed if the identity signature result matches the operator's signature.

[0226] The identity verification failure subunit is used to generate an identity verification result to indicate identity verification failure if the identity signature result is inconsistent with the operator's signature.

[0227] In some embodiments of this application, based on the above scheme, the key verification unit includes:

[0228] The operator verification signature verification subunit verifies the operator verification signature based on the target public key and obtains the signature verification result;

[0229] The key verification passed subunit is used to generate a key verification result to indicate that the key verification has passed if the signature verification result is consistent with the operator verification information;

[0230] The key verification failure subunit is used to generate a key verification result to indicate key verification failure if the signature verification result is inconsistent with the operator verification information.

[0231] In some embodiments of this application, based on the above scheme, the blockchain-based transaction verification device 700 further includes:

[0232] The management information update request receiving module is used to receive management information update requests. The management information update request includes a manager identity type, a manager identity signature, a newly added administrator identifier, a newly added administrator public key, manager verification information, and a manager verification signature. The manager identity type is used to identify the identity of the initiator of the management information update request. The manager verification signature is obtained by signing the manager verification information based on the newly added administrator private key corresponding to the newly added administrator public key.

[0233] The management public key determination module is used to determine the management public key of the initiator of the management information update request based on the manager's identity type.

[0234] The administrator identity verification module is used to verify the administrator's identity signature based on the administrator's public key and obtain the administrator verification result.

[0235] The key verification and identity verification module is used to perform key verification based on the newly added administrator public key, the administrator verification information, and the administrator verification signature to obtain the management information verification result.

[0236] The management information update module is used to update the management information corresponding to the identification information based on the newly added administrator identifier and the newly added administrator public key if both the administrator verification result and the management information verification result indicate that the verification has passed.

[0237] In some embodiments of this application, based on the above scheme, the blockchain-based transaction verification device 700 further includes:

[0238] The information sending module is used to send the identification information and the public key to be updated to the service node, so that the service node stores the mapping relationship between the identification information and the public key to be updated, and the service node is used to obtain the public key to be updated according to the identification information;

[0239] A service address information receiving module is used to receive service address information sent by the service node, wherein the service address information is used to uniquely identify the service node.

[0240] The service address index update module is used to update the service address index of the blockchain according to the mapping relationship between the identification information and the service address information.

[0241] In some embodiments of this application, based on the above solution, the transaction request sending module 730 includes:

[0242] The historical transaction information acquisition unit is used to acquire historical transaction information corresponding to the identification information from the blockchain based on the identification information.

[0243] The historical transaction information signing unit is used to sign the historical transaction information according to the target private key to obtain the verification information;

[0244] Based on the identification information and the verification information, the transaction request is generated and sent to the consensus node.

[0245] According to one aspect of the embodiments of this application, a blockchain-based transaction verification device is provided, characterized in that it includes:

[0246] A transaction request receiving module is used to receive a transaction request, which includes identification information, transaction address information and verification information, wherein the verification information is generated by signing with the target private key corresponding to the target public key.

[0247] The transaction address verification module is used to verify the transaction address based on the identification information and the transaction address information, and obtain the address verification result.

[0248] The target public key acquisition module is used to obtain the target public key corresponding to the identification information from the service node based on the identification information;

[0249] The legitimacy verification module is used to perform legitimacy verification based on the target public key and the verification information, and obtain the legitimacy verification result;

[0250] The transaction verification result module is used to determine the transaction verification result based on the address verification result and the legality verification.

[0251] In some embodiments of this application, based on the above scheme, the target public key acquisition module includes:

[0252] The service address information query unit is used to query service address information from the service address index of the blockchain based on the identification information. The address index table is used to store the mapping relationship between the identification information and the service address information.

[0253] The identification information sending unit is used to send the identification information to the service node corresponding to the service address information according to the service address information, so as to obtain the target public key corresponding to the identification information.

[0254] In some embodiments of this application, based on the above scheme, the transaction address verification module includes:

[0255] A hash calculation unit is used to perform hash calculation on the identification information to obtain a hash value;

[0256] The address verification unit is used to generate an address verification result to indicate that the address verification is successful if the hash value matches the transaction address information.

[0257] The address verification failure unit is used to generate an address verification result to indicate address verification failure if the hash value is inconsistent with the transaction address information.

[0258] In some embodiments of this application, based on the above scheme, the legality verification module includes:

[0259] A signature verification unit is used to verify the verification information based on the target public key to obtain a signature verification result;

[0260] The legitimacy verification unit is used to determine that the legitimacy verification is passed if the signature verification result is consistent with the historical transaction information corresponding to the identification information.

[0261] The legality verification failure unit is used to determine that the legality verification has failed if the transaction signature result is inconsistent with the historical transaction information corresponding to the identification information.

[0262] It should be noted that the apparatus provided in the above embodiments and the method provided in the above embodiments belong to the same concept, and the specific way in which each module performs the operation has been described in detail in the method embodiments, and will not be repeated here.

[0263] Figure 8 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0264] It should be noted that, Figure 8 The computer system 800 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0265] like Figure 8 As shown, the computer system 800 includes a Central Processing Unit (CPU) 801, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 802 or programs loaded from Storage Unit 808 into Random Access Memory (RAM) 803. The RAM 803 also stores various programs and data required for system operation. The CPU 801, ROM 802, and RAM 803 are interconnected via a bus 804. An Input / Output (I / O) interface 805 is also connected to the bus 804.

[0266] The following components are connected to I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to I / O interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 810 as needed so that computer programs read from it can be installed into storage section 808 as needed.

[0267] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by central processing unit (CPU) 801, it performs various functions defined in the system of this application.

[0268] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0269] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0270] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0271] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0272] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0273] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A blockchain-based transaction verification method, characterized in that, include: A transaction request is received, which includes identification information, transaction address information, and verification information. The identification information is used to uniquely identify the receiving node and corresponds to the target public key. The transaction address information is generated based on the identification information. The verification information is generated by signing the target private key corresponding to the target public key. The transaction address is verified based on the identification information and the transaction address information to obtain the address verification result. Based on the identification information, obtain the target public key corresponding to the identification information from the service node; A validity check is performed based on the target public key and the verification information to obtain a validity check result; The transaction verification result is determined based on the address verification result and the legality verification result.

2. The method according to claim 1, characterized in that, include: Receive a key update request, the key update request including identification information and the target public key; Update the public key to be updated corresponding to the identification information to the target public key; A transaction request is sent to the consensus node, wherein the transaction request includes the identification information and verification information, and the verification information is generated by signing with the target private key corresponding to the target public key; Receive a public key query request sent by the consensus node, wherein the public key query request contains the identification information; The target public key is sent to the consensus node according to the public key query request, so that the consensus node can verify the verification information based on the target public key.

3. The method according to claim 2, characterized in that, The key update request also includes an operator identity type, an operator signature, operator verification information, and an operator verification signature. The operator identity type is used to identify the identity of the initiator of the key update request, and the operator verification signature is obtained by signing the operator verification information based on the target private key. The step of updating the public key to be updated corresponding to the identification information to the target public key includes: Based on the identity type, determine the operator's public key of the initiator of the key update request; Based on the operator's public key, the operator's signature is verified to obtain the identity verification result; Key verification is performed based on the target public key, the operator verification information, and the operator verification signature to obtain the key verification result. If both the identity verification result and the key verification result indicate that the verification is successful, then the public key to be updated corresponding to the identification information will be updated to the target public key.

4. The method according to claim 3, characterized in that, The key update request also includes an administrator identifier, and determining the operator public key of the initiator of the key update request based on the identity type includes: If the identity type indicates that the initiator of the key update request is the receiving node, then the public key to be updated is obtained as the operator's public key; If the identity type indicates that the initiator of the key update request is an administrator node, then the administrator public key corresponding to the administrator identifier is obtained as the operator public key.

5. The method according to claim 3, characterized in that, The step of verifying the operator's signature based on the operator's public key to obtain the identity verification result includes: The key update request is signed using the operator's public key to obtain an identity signature result; If the identity signature result matches the operator's signature, an identity verification result is generated to indicate that the identity verification has passed. If the identity signature result is inconsistent with the operator's signature, an identity verification result is generated to indicate that the identity verification failed.

6. The method according to claim 3, characterized in that, The step of performing key verification based on the target public key, the operator verification information, and the operator verification signature to obtain the key verification result includes: Based on the target public key, the operator's signature is verified to obtain the signature verification result; If the signature verification result matches the operator verification information, a key verification result is generated to indicate that the key verification has passed. If the signature verification result is inconsistent with the operator verification information, a key verification result is generated to indicate that the key verification failed.

7. The method according to claim 2, characterized in that, The method further includes: The system receives a management information update request, which includes a manager identity type, a manager identity signature, a newly added administrator identifier, a newly added administrator public key, manager verification information, and a manager verification signature. The manager identity type is used to identify the identity of the initiator of the management information update request, and the manager verification signature is obtained by signing the manager verification information based on the newly added administrator private key corresponding to the newly added administrator public key. Based on the administrator's identity type, determine the administrator's public key of the initiator of the management information update request; Based on the public key of the management party, the identity signature of the manager is verified to obtain the manager verification result; The key verification is performed based on the newly added administrator public key, the administrator verification information, and the administrator verification signature to obtain the management information verification result. If both the administrator verification result and the management information verification result indicate that the verification is successful, then the management information corresponding to the identification information is updated according to the newly added administrator identifier and the newly added administrator public key.

8. The method according to claim 2, characterized in that, The method further includes: The identification information and the public key to be updated are sent to the service node so that the service node stores the mapping relationship between the identification information and the public key to be updated. The service node is used to obtain the public key to be updated based on the identification information. Receive service address information sent by the service node, wherein the service address information is used to uniquely identify the service node; The service address index of the blockchain is updated based on the mapping relationship between the identification information and the service address information.

9. The method according to claim 2, characterized in that, Sending a transaction request to the consensus node includes: Based on the identification information, retrieve the historical transaction information corresponding to the identification information from the blockchain; The historical transaction information is signed based on the target private key to obtain the verification information; Based on the identification information and the verification information, the transaction request is generated and sent to the consensus node.

10. The method according to claim 1, characterized in that, The step of obtaining the target public key corresponding to the identification information from the service node based on the identification information includes: Based on the identification information, service address information is queried from the service address index of the blockchain. The address index table is used to store the mapping relationship between identification information and service address information. Based on the service address information, the identification information is sent to the service node corresponding to the service address information to obtain the target public key corresponding to the identification information.

11. The method according to claim 1, characterized in that, Transaction address verification is performed based on the identification information and the transaction address information to obtain the address verification result, including: The identification information is hashed to obtain a hash value; If the hash value matches the transaction address information, an address verification result is generated to indicate that the address verification is successful. If the hash value does not match the transaction address information, an address verification result is generated to indicate that the address verification failed.

12. The method according to claim 1, characterized in that, The step of performing a legitimacy verification based on the target public key and the verification information to obtain a legitimacy verification result includes: The verification information is verified based on the target public key to obtain a signature verification result; If the signature verification result is consistent with the historical transaction information corresponding to the identification information, then the legality verification is deemed successful. If the transaction signature result is inconsistent with the historical transaction information corresponding to the identification information, the legality verification is deemed to have failed.

13. A blockchain-based transaction verification device, characterized in that, include: A transaction request receiving module is used to receive a transaction request, which includes identification information, transaction address information and verification information. The identification information is used to uniquely identify the receiving node and corresponds to the target public key. The transaction address information is generated by encrypting the identification information. The verification information is generated by signing the target private key corresponding to the target public key. The transaction address verification module is used to verify the transaction address based on the identification information and the transaction address information, and obtain the address verification result. The target public key acquisition module is used to obtain the target public key corresponding to the identification information from the service node based on the identification information; The legitimacy verification module is used to perform legitimacy verification based on the target public key and the verification information, and obtain the legitimacy verification result; The transaction verification result module is used to determine the transaction verification result based on the address verification result and the legality verification.

14. The apparatus according to claim 13, characterized in that, The device further includes: An update request receiving module is used to receive a key update request, wherein the key update request includes identification information and a target public key; The public key update module is used to update the public key to be updated corresponding to the identification information to the target public key; A transaction request sending module is used to send a transaction request to a consensus node, wherein the transaction request includes the identification information and verification information, and the verification information is generated by signing with the target private key corresponding to the target public key; A query request receiving module is used to receive a public key query request sent by the consensus node, wherein the public key query request contains the identification information; The public key sending module is used to send the target public key to the consensus node according to the public key query request, so that the consensus node can verify the verification information according to the target public key.

15. An electronic device, characterized in that, include: processor; Memory for storing the executable instructions of the processor; The processor is configured to execute the blockchain-based transaction verification method according to any one of claims 1 to 12 by executing the executable instructions.

16. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the blockchain-based transaction verification method as described in any one of claims 1 to 12.

17. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain-based transaction verification method as described in any one of claims 1 to 12.

Images