Transaction processing method and device of block chain network, product, equipment and medium

Abstract

The invention discloses a transaction processing method and device for a block chain network, a product, equipment and a medium, and the method comprises the steps: the block chain network comprises a first network layer and N second network layers, and the first network layer is bound with a first public key of a first object, the N second network layers are used for executing the transaction of the first object based on the first public key bound in the first network layer; any second network layer receives the business transaction of the first object; the business transaction carries the second public key and certification information for binding the second public key in the first network layer; acquiring associated storage information bound by the first public key in the first network layer; verifying the consistency between the second public key and the first public key based on the associated storage information and the proof information; and if the second public key is consistent with the first public key, executing the business transaction. By adopting the method and the device, the convenience and the reliability of managing the public key by the object can be improved, and the uniformity and the accuracy of executing the transaction of the object by each second network layer are ensured.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more particularly to a transaction processing method, apparatus, product, device, and medium for a blockchain network. Background Technology

[0002] In a blockchain layer 2 network, there can be one first network layer and multiple second network layers. Multiple second network layers can depend on the same first network layer. Each second network layer can be used to execute blockchain transactions in the blockchain network, while the first network layer can be used to verify the transactions executed by each second network layer.

[0003] In existing applications, each second network layer can store the object's public key. Objects can manage their own public keys in each second network layer, and each second network layer can verify and execute transactions initiated by the object based on its stored public key. However, because objects need to manage their public keys in multiple second network layers, this easily leads to inconsistencies or errors in the public keys managed by the object across different second network layers. Consequently, the second network layers cannot process the transactions initiated by the object in a unified and accurate manner. Summary of the Invention

[0004] This application provides a transaction processing method, apparatus, product, device, and medium for a blockchain network, which can improve the convenience and reliability of public key management for objects and ensure the uniformity and accuracy of transactions processed by objects in each second network layer.

[0005] This application provides a transaction processing method for a blockchain network. The blockchain network includes a first network layer and N second network layers, where N is a positive integer. The first network layer is bound to a first public key of a first object. The N second network layers are used to execute transactions of the first object based on the first public key bound to the first network layer. The method is applied to any of the second network layers and includes:

[0006] Receive a business transaction initiated by the first object; the business transaction carries the second public key passed in by the first object, and the proof information of binding the passed second public key in the first network layer;

[0007] Obtain the first public key of the first object and the associated storage information bound in the first network layer;

[0008] Based on the associated storage information and proof information, the consistency between the incoming second public key and the bound first public key is verified;

[0009] If the second public key passed in matches the first public key bound to it, the business transaction will be executed.

[0010] This application provides a transaction processing device for a blockchain network. The blockchain network includes a first network layer and N second network layers, where N is a positive integer. A first public key of a first object is bound to the first network layer. The N second network layers are used to execute transactions of the first object based on the first public key bound to the first network layer. The device is applied to any of the second network layers. The device includes:

[0011] The receiving module is used to receive business transactions initiated by the first object; the business transaction carries the second public key passed in by the first object, and the proof information of binding the passed second public key in the first network layer;

[0012] The acquisition module is used to acquire the associated storage information of the first public key of the first object bound in the first network layer;

[0013] The verification module is used to verify the consistency between the incoming second public key and the bound first public key based on the associated storage information and proof information;

[0014] The execution module is used to execute business transactions if the passed-in second public key matches the bound first public key.

[0015] Optionally, the first public key is bound to the state tree of the first network layer; the method by which the acquisition module obtains the associated storage information of the first object's first public key bound in the first network layer includes:

[0016] Query the root of the state tree in the state tree of the first network layer;

[0017] Obtain the target path information from the first public key bound to the first object in the state tree of the first network layer to the root of the state tree;

[0018] The root and target path information of the queried state tree are identified as associated storage information.

[0019] Optionally, the proof information is the Merkel proof information of the second public key in the state tree of the first network layer; the verification module verifies the consistency between the incoming second public key and the bound first public key based on the associated storage information and the proof information, including the following methods:

[0020] Based on the second public key, target path information, and proof information, the state tree of the first network layer is reconstructed to generate the root of the reconstructed state tree of the first network layer.

[0021] Based on the reconstructed state tree root and the queried state tree root, the consistency between the incoming second public key and the bound first public key is verified.

[0022] Optionally, the verification module verifies the consistency between the incoming second public key and the bound first public key based on the reconstructed state tree root and the queried state tree root, including the following methods:

[0023] Compare the reconstructed state tree root with the queried state tree root;

[0024] If the reconstructed state tree root is equal to the queried state tree root, then it is determined that the second public key passed in is consistent with the first public key bound to it.

[0025] If the reconstructed state tree root is different from the queried state tree root, then it is determined that the second public key passed in is inconsistent with the first public key bound to it.

[0026] Optionally, a public key management contract is deployed in the first network layer. The first public key is stored in the state tree of the first network layer based on the public key management contract. Both the first public key and the public key management contract correspond to state nodes in the state tree of the first network layer.

[0027] In the state tree of the first network layer, the path information from the state node of the first public key to the state node of the public key management contract includes the object identifier of the first object, and the path information from the state node of the public key management contract to the root of the state tree includes the contract address of the public key management contract.

[0028] The target path information includes the object identifier stored for the first object in any network layer, and the contract address stored for the public key management contract.

[0029] Optionally, the business transaction also carries a first signature, which is obtained by signing the business transaction using the first private key corresponding to the first public key;

[0030] The execution module executes business transactions in the following ways:

[0031] The first signature is verified using the passed-in second public key;

[0032] If the first signature is successfully verified, the business transaction is executed in any second network layer.

[0033] Optionally, the business transaction is a resource transfer transaction, which is used to transfer the target resource of the first object to the second object in any second network layer; the execution module executes the business transaction in any second network layer in the following ways:

[0034] Obtain the target resource of the first object from its blockchain address in any second network layer;

[0035] The acquired target resources are transferred to the blockchain address of the second object in any second network layer.

[0036] Optionally, the first signature is obtained by encrypting the transaction hash of the business transaction using the first private key; the execution module verifies the first signature using the passed-in second public key, including:

[0037] The first signature is decrypted using the passed-in second public key to obtain the decryption hash;

[0038] Perform hash calculations on the business transactions to obtain the calculated hash of the business transactions;

[0039] If the calculated hash is equal to the decrypted hash, then the first signature verification is successful.

[0040] If the calculated hash and the decrypted hash are not equal, then the verification of the first signature has failed.

[0041] Optionally, the first network layer is used to receive a binding transaction initiated by the first object. The binding transaction includes the object identifier of the first object and the first public key. The binding transaction carries a second signature, which is obtained by signing the binding transaction using the first private key corresponding to the first public key.

[0042] The first network layer is used to verify the second signature using the first public key in the binding transaction, and after the second signature is successfully verified, it binds the first public key to the first object in the state tree of the first network layer based on the object identifier of the first object.

[0043] Optionally, the first network layer is used to receive a public key update transaction initiated by the first object. The public key update transaction contains the third public key to be updated. The public key update transaction carries a third signature, which is obtained by signing the public key update transaction using the first private key corresponding to the first public key.

[0044] The first network layer is used to verify the third signature based on the first public key bound to the first object in the state tree, and to update the first public key bound to the first object in the state tree of the first network layer to the third public key after the third signature is successfully verified.

[0045] Optionally, the business transaction is sent from the object client of the first object to any second network layer; the transaction processing apparatus further includes a prompting module, which is used for:

[0046] If the passed-in second public key matches the bound first public key, then after executing the business transaction, the execution result of the business transaction is obtained and returned to the object client; and,

[0047] If the second public key passed in does not match the first public key bound to it, an invalid business transaction message will be generated and returned to the client.

[0048] This application provides a computer device, including a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the processor performs the method of this application.

[0049] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the method described in the above-mentioned aspect.

[0050] According to one aspect of this application, a computer program product is provided, comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the methods provided in the various alternative embodiments described above.

[0051] The blockchain network in this application may include a first network layer and N second network layers, where N is a positive integer. The first network layer is bound to a first public key of a first object. The N second network layers are used to execute transactions of the first object based on the first public key bound in the first network layer. Any second network layer can receive a business transaction initiated by the first object. The business transaction carries a second public key passed in by the first object, as well as proof information for binding the passed second public key in the first network layer. It also obtains the associated storage information for binding the first public key of the first object in the first network layer. Based on the associated storage information and proof information, it verifies the consistency between the passed second public key and the bound first public key. Therefore, if the passed second public key is consistent with the bound first public key, the business transaction can be executed. Therefore, the method proposed in this application can bind the public key (such as the first public key) of the first object in the first network layer. If the first object needs to change its public key later, it can directly modify the public key bound to it in the first network layer. This allows the first object to maintain only the public key bound to it in the first network layer when maintaining its public key, thus improving the convenience and reliability of the first object managing its public key. Furthermore, when the second network layer receives a transaction initiated by the first object (such as an object transaction), it can first verify the consistency between the public key (such as the second public key) passed by the first object and the public key bound to the first object in the first network layer (such as the first public key). Only when the passed public key is verified to be consistent with the bound public key will the transaction initiated by the first object be executed. In other words, each second network layer relies on the public key bound to the first object in the first network layer when executing a transaction initiated by the first object. This allows each second network layer to rely on the public key bound to the first object in the first network layer, achieving uniformity and accuracy in processing transactions initiated by the first object. Attached Figure Description

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

[0053] Figure 1 This is a schematic diagram of the network architecture of a blockchain network provided in an embodiment of this application;

[0054] Figure 2 This is a schematic diagram of a transaction verification scenario provided in an embodiment of this application;

[0055] Figure 3 This is a schematic flowchart of a transaction processing method for a blockchain network provided in an embodiment of this application;

[0056] Figure 4 This is a schematic diagram of the state tree structure of a first network layer provided in an embodiment of this application;

[0057] Figure 5 This is a schematic diagram illustrating a scenario of updating the first public key bound to a first object, as provided in an embodiment of this application.

[0058] Figure 6 This is a schematic diagram of a public key registration process provided in an embodiment of this application;

[0059] Figure 7 This is a schematic diagram illustrating a transaction execution process in the second network layer, provided by an embodiment of this application.

[0060] Figure 8 This is a schematic diagram of the structure of a transaction processing device for a blockchain network provided in an embodiment of this application;

[0061] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0062] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0063] This application relates to blockchain-related technologies. Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying platform, a platform product service layer, and an application service layer.

[0064] The underlying blockchain platform can include modules for user management, basic services, smart contracts, and operations. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user identities and blockchain addresses (access management). Under authorization, it also monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic services module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic services first perform interface adaptation parsing and authentication (interface adaptation), and then encrypt the business information using a consensus algorithm (consensus). The management module (network communication) ensures that the encrypted data is transmitted completely and consistently to the shared ledger and recorded. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). Based on the contract terms, the module calls keys or other events to trigger execution and complete the contract logic. It also provides functions for contract upgrades and cancellations. The operations module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization during product launch, such as alarms, network monitoring, and monitoring of node device health.

[0065] The platform's product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities, along with the specific characteristics of their business needs, to implement blockchain-based business logic. The application service layer provides blockchain-based application services to business stakeholders.

[0066] The blockchain network in this application may include a first network layer and N second network layers. In this application, the public key of an object can be bound through the first network layer. Thus, each second network layer can verify the transaction initiated by the object through the public key bound to the object in the first network layer, so as to execute the transaction initiated by the object.

[0067] First, it should be noted that all data collected in this application (such as transactions, public keys of objects, private keys of objects, object identifiers of objects, state trees of the first network layer, and other related data) are collected with the consent and authorization of the object to which the data belongs (such as users, institutions, or enterprises), and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant regions.

[0068] Here, the relevant technical concepts involved in this application are explained:

[0069] Smart contracts are computer programs that can automatically execute contract terms and have characteristics such as event-driven, value transfer, and automatic execution.

[0070] Layer 2 blockchain networks: Layer 1 networks are the underlying blockchain, while Layer 2 networks are built on top of Layer 1. Transactions in Layer 2 networks do not require complex decentralized consensus, thus significantly reducing transaction costs. Furthermore, Layer 2 transactions only require the batch submission of necessary compressed transaction data and status to the Layer 1 network. With validity proofs or challenge mechanisms, the Layer 1 network can guarantee the correctness of transaction execution in the Layer 2 network. Therefore, while reducing transaction costs, Layer 2 networks still maintain the same security as Layer 1 networks.

[0071] Account abstraction: Account abstraction refers to using smart contracts as user accounts instead of external accounts (EOAs). In account abstraction, the account is actually a customizable and programmable smart contract, allowing users to change the public and private keys of the account.

[0072] Please see Figure 1 , Figure 1 This is a schematic diagram of the network architecture of a blockchain network provided in an embodiment of this application. Figure 1 As shown, the network architecture can include an object client and a blockchain network. The blockchain network can include a first network layer (which can be one) and N second network layers, where N is a positive integer. The object client can initiate transactions to the second network layer, and the second network layer can execute the transactions initiated by the object client. The second network layer can construct a transaction batch by accumulating several executed transactions, and can submit the transaction batch to the first network layer, so that the first network layer can verify (or confirm) the transactions executed by the second network layer.

[0073] The aforementioned client can be a client in a terminal device. Both the first network layer and the second network layer can contain several blockchain nodes, and a blockchain node can be composed of one or more servers.

[0074] Optionally, the servers constituting blockchain nodes can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The terminal devices used for transaction clients can be smart terminals such as smartphones, tablets, laptops, desktop computers, smart TVs, in-vehicle terminals, and smart home devices.

[0075] In this context, the object client can be a client of a first object, which can be any user in the blockchain network. The object client can request the first network layer of the blockchain network to update and bind the first object's object public key; that is, the first object's object public key can be stored and managed by the first network layer. Subsequently, the first object can initiate its own transactions to various second network layers from the object client. The second network layer receiving the transaction can then verify the transaction based on the object public key bound to the first object in the first network layer, and execute the transaction upon successful verification. In other words, the first object can have its own object account in each second network layer, and each second network layer can process the transactions initiated by the first object. However, which second network layers the first object specifically initiates transactions with can be determined based on the actual application scenario, and the process of the first object initiating and executing transactions with each second network layer can be independent of each other.

[0076] Please see also Figure 2 , Figure 2 This is a schematic diagram illustrating a transaction verification scenario provided in an embodiment of this application. For example... Figure 2 As shown, the process of verifying and executing a business transaction initiated by the first object by any second network layer can be used as an example for explanation. This second network layer can receive a business transaction initiated by the first object. This business transaction can carry a second public key passed in by the first object, and proof information that the second public key is bound in the first network layer. This proof information is the information provided by the first object to prove that its passed-in second public key has been bound in the first network layer.

[0077] The first public key of the first object is bound in the first network layer. Any second network layer can also obtain the associated storage information of the first public key of the first object in the first network layer. This associated storage information is the information related to the binding of the first public key generated when the first public key is bound in the first network layer. Therefore, it can be understood that this associated storage information can also prove the binding of the first public key in the first network layer to a certain extent.

[0078] The second network layer can use the associated storage information and the proof information carried by the business transaction to verify the consistency between the second public key passed by the first object and the first public key bound by the first object in the first network layer, that is, to verify whether the first public key and the second public key are consistent.

[0079] If any second network layer verifies that the first public key matches the second public key, then that second network layer can determine that the verification of the second public key carried in the business transaction initiated by the first object has been successful, and can execute the business transaction initiated by the first object. Conversely, if any second network layer verifies that the first public key does not match the second public key, then that second network layer can determine that the verification of the second public key carried in the business transaction initiated by the first object has failed, and can refuse to execute the business transaction initiated by the first object. That is, in this case, any second network layer will not execute the business transaction initiated by the first object, and the business transaction execution fails. The specific process described above can also be found in the relevant descriptions in the following embodiments of this application.

[0080] As can be seen, by using the method provided in this application, the object's public key can be bound to the first network layer. Subsequently, the object only needs to maintain its own object public key in the first network layer. After receiving a transaction initiated by the object, each second network layer can verify the transaction initiated by the object based on the object public key bound to the object in the first network layer. Only after successful verification will the transaction initiated by the object be executed. This ensures that each second network layer relies on the object public key bound to the object in the first network layer to execute the transaction initiated by the object, thus guaranteeing the accuracy and consistency of the execution of the transaction initiated by the object by each second network layer.

[0081] Please see Figure 3 , Figure 3 This is a flowchart illustrating a transaction processing method for a blockchain network provided in an embodiment of this application. The blockchain network of this application can be a two-layer blockchain network, which may include a first network layer (which may be one) and N second network layers, where N is a positive integer. The specific value of N can be determined according to the actual application scenario. The first network layer may be bound to the first public key of a first object, which can be any user in the blockchain network. All N second network layers can execute the transaction initiated by the first object through the first public key bound to the first object in the first network layer.

[0082] like Figure 3 As shown, the method may include:

[0083] Step S101: Receive a business transaction initiated by the first object; the business transaction carries the second public key passed in by the first object, and the proof information of binding the passed second public key in the first network layer.

[0084] Optionally, the first network layer may include several blockchain nodes, which can be used to execute the business operations within the first network layer. Similarly, the second network layer may also include several blockchain nodes, which can be used to execute the business operations within the second network layer. A blockchain node can be a single computer device or a cluster of multiple computer devices. Therefore, it is understood that in the following processes, the operations performed by the first network layer can be executed by the blockchain nodes within the first network layer, and the operations performed by the second network layer can be executed by the blockchain nodes within the second network layer.

[0085] The second network layer can be used to execute business transactions within the blockchain network, while the first network layer can be used to verify the business transactions executed by the second network layer and to perform consensus and on-chain processing of these transactions. The second network layer can be one of the aforementioned two-layer networks, and the first network layer can be one of the aforementioned single-layer networks.

[0086] The first public key bound to the first object in the first network layer mentioned above is the object public key (which can be referred to as the public key) that the first object can (or needs) use when conducting transactions in the blockchain network. This first public key can be bound to the state tree of the first network layer. This state tree can be used to record various network states of the first network layer (such as transaction state, network configuration state, etc.). This state tree can be a Merkle tree, and the first public key bound to the first object can correspond to a state node (i.e., a Merkle node) in the state tree of the first network layer.

[0087] Furthermore, a public key management contract can also be deployed (i.e., configured) in the first network layer. This public key management contract can be a smart contract used to manage and bind the public keys of objects in the blockchain network. Therefore, the first public key of the first object can be stored and bound in the state tree of the first network layer based on this public key management contract. This public key management contract can also correspond to a state node in the state tree of the first network layer. This state node can be used to record contract information related to the public key management contract, such as contract source code, contract methods, contract events, etc.

[0088] In the state tree of the first network layer, the path information from the state node of the first public key to the state node of the public key management contract can include the object identifier of the first object. This means that the public key management contract can store and bind the first public key of the first object through its object identifier. Furthermore, the path information from the state node of the public key management contract to the root of the state tree (also known as the Merkle root, which is also a state node in the state tree) can include the contract address of the public key management contract. This means that in the state tree of the first network layer, the public key management contract can be maintained and stored based on its contract address.

[0089] In this application, the maintenance of a public key management contract in the first network layer can be based on key-value pairs, as well as the object public keys bound to each object under the public key management contract. For example, in the state tree of the first network layer, the object identifier of the first object and the first public key bound to the first object can be a key-value pair. The object identifier of the first object can be the key, and the first public key bound to the first object can be the value corresponding to the key. The key in the key-value pair can be used to indicate the path to the corresponding value. Therefore, in this key-value pair, the object identifier of the first object is the path information from the first public key bound to the first object in the state tree to the public key management contract.

[0090] For example, in the state tree of the first network layer, there can be a key-value pair between the public key management contract and its contract address. The contract address of the public key management contract can be the key, and the public key management contract can be the value corresponding to the key. In this key-value pair, the contract address of the public key management contract can be the path information from the root of the state tree to the public key management contract in the state tree of the first network layer.

[0091] Understandably, path information (such as the object identifier of the first object or the contract address of the public key management contract) can be used to indicate the two connected state nodes. For example, the object identifier of the first object can be used to indicate the state node of the first public key and the state node of the public key management contract; similarly, the contract address of the public key management contract can be used to indicate the state node of the connected public key management contract and the root of the state tree.

[0092] The execution entity in this application embodiment can be any second network layer (hereinafter referred to as any second network layer). In other words, each second network layer can execute the process described in this application embodiment. This application embodiment can be described by taking any second network layer to execute the process in this application embodiment as an example. The operation executed by any second network layer can be executed by the blockchain node in any second network layer.

[0093] The second network layer can receive business transactions initiated by the first object. The business transaction can be any business-related transaction initiated by the first object in the second network layer, such as a resource transfer transaction or a data storage transaction of the first object, etc.

[0094] In this application, all operations performed by the first object can be performed by the object client of the first object, which can be a client logged into the first object's account in the blockchain network. Therefore, it can be understood that the business transaction can be triggered and initiated by the first object in the object client, and then generated and sent by the object client to any second network layer.

[0095] The business transaction may carry a second public key passed in by the first object. The passed second public key may be the public key that the first object enters in the object client and binds in the first network layer, or the passed second public key may be pre-stored locally on the object client of the first object and can be directly obtained by the object client.

[0096] The transaction can also carry proof that the second public key has been bound in the first network layer. This proof is essentially the first object's statement that it has bound the second public key in the first network layer. Understandably, if the second public key is correct, it should be the same as the first public key bound by the first object in the first network layer.

[0097] The proof information carried in the business transaction can be the Merkel proof information of the second public key in the state tree of the first network layer. This Merkel proof information can also be called Merkel path information. This proof information can be obtained by the object client querying the first network layer. For example, the object client can send a query request to the first network layer, which can carry the first public key bound to the first object. The object client can use this query request to query the Merkel proof information of the first public key bound to the first object in the state tree of the first network layer. The first network layer can return the queried Merkel proof information to the object client and use this Merkel proof information as proof information of the object public key bound to the first object.

[0098] Through the above process, any of the second network layers can obtain the business transaction initiated by the first object, the second public key carried by the business transaction, and the proof information of binding the second public key in the first network layer.

[0099] Step S102: Obtain the associated storage information of the first public key of the first object bound in the first network layer.

[0100] Optionally, any of the aforementioned second network layers may also obtain associated storage information of the first public key of the first object being bound in the first network layer. This associated storage information may be information related to the binding of the first public key generated when the first public key of the first object is bound in the first network layer. For example, the process by which any of the second network layers obtains this associated storage information may include:

[0101] Any second network layer can query the state tree root in the state tree of the first network layer. Any second network layer can also obtain the target path information from the first public key bound to the first object in the state tree of the first network layer to the state tree root. This target path information can be the path information from the state node of the first public key of the first object in the state tree of the first network layer to the state tree root. Any second network layer can use the queried state tree root and the obtained target path information as associated storage information for binding the first public key bound to the first object in the first network layer.

[0102] Since the path information from the state of the first public key of the first object to the state node of the aforementioned public key management contract includes the object identifier of the first object, and the path information from the state node of the public key management contract to the root of the state tree in the state tree of the first network layer includes the contract address of the public key management contract, the target path information obtained by any of the aforementioned second network layers may include the object identifier stored for the first object and the contract address stored for the public key management contract in that network layer.

[0103] Please see Figure 4 , Figure 4 This is a schematic diagram of the state tree structure of a first network layer provided in an embodiment of this application. Figure 4 As shown, vault can be the contract address of the aforementioned public key management contract, userId1 can be the object identifier of the aforementioned first object, userId2 can be the object identifier of another object besides the first object, publicKey1 can be the first public key bound to the first object by the state tree of the first network layer, and publicKey2 can be the object public key bound to the other object.

[0104] Here, the state nodes of the state tree in the first network layer can include state_root (the root of the state tree), state nodes with the value of address1_state, address2_state, address3_state, vault_state (the state node corresponding to the public key management contract), publicKey1 (the state node corresponding to the first public key of the first object), and publicKey2 (the state node corresponding to the object public key of the other object). Address1 through address3 can be the contract addresses of other smart contracts deployed in the first network layer; that is, the state nodes with the values ​​of address1_state, address2_state, and address3_state can be the state nodes corresponding to other smart contracts deployed in the first network layer. Different state nodes in the state tree can be addressed and associated through corresponding keys (belonging to path information).

[0105] It is understandable that the state nodes with the value "address1_state", "address2_state", and "address3_state" can be followed by other state nodes. However, this application does not focus on the state nodes connected to the state nodes with the values ​​"address1_state", "address2_state", and "address3_state". Therefore, Figure 4 It is not shown in the drawing.

[0106] The path information from the state node with value publicKey1 (i.e., the state node of the first public key of the first object) to the state node with value vault_state (i.e., the state node of the public key management contract) can include the object identifier userId1 of the first object.

[0107] The value is the path information from the state node of vault_state (i.e., the state node of the public key management contract) to the root of the state tree of the first network layer, which can include the contract address vault of the public key management contract.

[0108] Therefore, the aforementioned target path information could include the object identifier userId1 of the first object and the contract address vault. The aforementioned proof information of the second public key (if the proof information is valid, then the proof information is also the proof information of the bound first public key) could include a state node with the value publicKey2, a state node with the value address1_state, a state node with the value address2_state, and a state node with the value address3_state.

[0109] Therefore, as Figure 4 As shown, the root of the state tree of the first network layer can be reconstructed and derived using publicKey1, publicKey2, address1_state, address2_state, address3_state, userId1, and the contract address vault.

[0110] Step S103: Based on the associated storage information and proof information, verify the consistency between the incoming second public key and the bound first public key.

[0111] Optionally, any of the above-mentioned second network layers can reconstruct the state tree of the first network layer using the input second public key (i.e., the second public key carried in the business transaction), the proof information of the second public key, and the obtained target path information. This reconstruction process can be understood as the process of deriving and reconstructing the state tree root in the state tree of the first network layer using the input second public key, target path information, and proof information, so as to generate the reconstructed state tree root of the state tree of the first network layer.

[0112] Furthermore, any second network layer can verify the consistency between the incoming second public key and the bound first public key (i.e., the first public key bound to the first object in the first network layer) through the reconstructed state tree root and the queried state tree root, as described below.

[0113] The second network layer can compare the reconstructed state tree root with the queried state tree root. If the reconstructed state tree root is equal to the queried state tree root (i.e., the same), it can be determined that the input second public key is consistent with the bound first public key (i.e., the same). Conversely, if the reconstructed state tree root is not equal to the queried state tree root (i.e., different), it can be determined that the input second public key is inconsistent with the bound first public key (i.e., different).

[0114] Through the above process, the consistency between the incoming second public key and the bound first public key is verified. Figure 4For example, the verification can include two Merkle proofs: one for verifying the value of publicKey1 corresponding to the key userId1 and the other for verifying the value of vault_state corresponding to the key vault. This proof can also be called a key-value pair proof.

[0115] Step S104: If the second public key passed in matches the first public key bound to it, then execute the business transaction.

[0116] Optionally, any of the above-mentioned second network layers may determine that the second public key carried in the business transaction initiated by the first object has been successfully verified when it is verified that the incoming second public key is consistent with the bound first public key, and may execute the business transaction initiated by the first object.

[0117] The business transaction initiated by the first object may also carry a first signature. This first signature can be obtained by the object client signing the business transaction using the first private key corresponding to the first public key, or it can be obtained by the object client encrypting the hash value of the business transaction (which can be called the transaction hash of the business transaction) using the first private key.

[0118] The first private key corresponding to the first public key can be a private key that forms a public-private key pair with the first public key. Data encrypted with the first public key can be decrypted with the first private key, and vice versa.

[0119] Therefore, when any of the above second network layers verifies that the first public key and the second public key are consistent, it can use the passed-in second public key to verify the first signature (i.e., signature verification). If the first signature is successfully verified, the business transaction can be executed in any of the second network layers.

[0120] For example, the process by which any second network layer verifies the first signature using the incoming second public key may include:

[0121] The second network layer can use the incoming second public key to decrypt the first signature to obtain a decrypted hash (which can be called a decryption hash). The second network layer can also perform hash calculation on the received business transaction to calculate the hash of the business transaction (which can be called a calculation hash).

[0122] The second network layer can compare the decryption hash and the calculated hash. If the calculated hash is equal to the decryption hash (i.e., the same), the verification of the first signature is successful; otherwise, if the calculated hash is not equal to the decryption hash (i.e., different), the verification of the first signature fails.

[0123] After executing a business transaction, any second network layer can obtain the execution result of the business transaction (such as the result of execution failure or execution success) and return the execution result to the object client. The object client can output the execution result for the first object to view, so as to indicate to the first object that the business transaction it initiated has failed or succeeded.

[0124] If it is verified that the second public key passed in is inconsistent with the first public key bound to it, then any second network layer can confirm that the verification of the second public key carried in the business transaction has failed, and can prohibit the execution of the business transaction initiated by the first object, and can generate a prompt message that the business transaction is invalid, and can also return the prompt message that the business transaction is invalid to the object client, and the object client can output the prompt message to indicate to the first object that the business transaction it initiated is invalid.

[0125] For example, the above-mentioned business transaction may be a resource transfer transaction of the first object, which may be a transaction for transferring the target resources (such as a specified amount of resources) of the first object in any second network layer to the second object. The second object may be any user in the blockchain network, and the second object and the first object may be different users in the blockchain network.

[0126] Therefore, if the first public key is verified to match the second public key, the process of executing a business transaction in either of the second network layers can include:

[0127] The second network layer can obtain the target resource of the first object from the blockchain address of the first object in the second network layer (which can be understood as the object account of the first object in the second network layer, which can be derived from the object public key (such as the bound first public key) of the first object in the first network layer), such as a general fund in the object account of the first object.

[0128] The second network layer can transfer the acquired target resource to the blockchain address of the second object in the second network layer. Similarly, the blockchain address can be the object account of the second object in the second network layer, and the object account can be derived from the object public key bound to the second object in the first network layer.

[0129] Through the above process, the execution of the resource transfer transaction initiated by any second network layer on the first object is realized, that is, the target resources held by the first object in any second network layer are transferred to the second object in any second network layer.

[0130] More specifically, the first public key bound to the first object in the first network layer can be obtained by registering the first object in the first network layer, or it can be obtained by updating the object public key registered by the first object in the first network layer. Here, taking the example of the first public key being the object public key obtained by the first object registering in the first network layer, the process of registering (i.e., binding) the object public key of the first object in the first network layer is described as follows.

[0131] The first network layer can receive a binding transaction (also known as a registration transaction) initiated by the first object. This binding transaction can also be initiated by the first object through an object client to the first network layer. The binding transaction can include the object identifier of the first object and the first public key to be bound. Optionally, the object identifier of the first object can be generated by the first object itself based on a random algorithm, and the public-private key pair (the first public key and first private key) can also be generated by the first object itself (e.g., generated by the first object calling a key generation algorithm in the object client). The binding transaction can also carry a second signature, which can be obtained by signing the binding transaction using the first private key corresponding to the first public key.

[0132] The first network layer can perform a coincidence check on the object identifier of the first object in the binding transaction, that is, check whether the object identifier of the first object coincides with the existing object identifier of other objects in the blockchain network (i.e., they are the same). If the object identifier of the first object coincides with the existing object identifier of other objects, the first network layer can refuse to bind the public key of the first object through the object identifier of the first object, and the binding transaction will fail. The first network layer can also inform the object client that the binding transaction has failed.

[0133] If the object identifier of the first object does not overlap with the existing object identifier of other objects, the first network layer can use the first public key that needs to be bound in the binding transaction to verify the second signature (i.e., signature verification). After the second signature is successfully verified, the first public key can be bound to the first object in the state tree of the first network layer through the object identifier of the first object in the binding transaction. This realizes the process of binding the first public key of the first object in the first network layer.

[0134] The principle for verifying the second signature can be the same as the principle for verifying the first signature.

[0135] Furthermore, after the first object binds the aforementioned first public key in the first network layer, the bound first public key can also be updated in the first network layer. This process can include:

[0136] The first object can initiate a public key update transaction to the first network layer through an object client. The first network layer can receive this public key update transaction initiated by the first object. As the name suggests, this public key update transaction is used to update the first public key bound to the first object in the first network layer.

[0137] The public key update transaction may include the third public key to be updated. The public key update transaction may carry a third signature, which may be obtained by signing the public key update transaction using the first private key corresponding to the first public key (i.e. the private key corresponding to the public key that needs to be updated that was originally bound).

[0138] The first network layer can verify the third signature using the first public key bound to the first object in the state tree. After successful verification, the first public key bound to the first object in the first network layer's state tree is updated (i.e., switched) to the third public key. This achieves the update and switching of the first public key bound to the first object in the first network layer. Subsequently, the first object can use the updated third public key to process its transactions in the blockchain network. This third public key also has a corresponding private key. In this sense, updating the first object's object public key can be understood as updating the first object's object account.

[0139] The principle for verifying the third signature can be the same as the principle for verifying the first signature.

[0140] Please see Figure 5 , Figure 5 This is a schematic diagram illustrating a scenario of updating the first public key bound to a first object, as provided in an embodiment of this application. Figure 5 As shown, the public-private key pair that needs to be updated includes the first public key and the first private key corresponding to the first public key. The public-private key pair that needs to be updated to include the third public key and the second private key corresponding to the third public key. Updating the object public key of the first object can be understood as simultaneously updating the object private key (which can be simply referred to as the private key) of the first object.

[0141] The object client can send a public key update transaction to the first network layer. The public key update transaction can contain the third public key to be updated. The public key update transaction can be signed with the first private key corresponding to the first public key. For example, the public key update transaction can carry the third signature obtained by signing with the first private key.

[0142] The first network layer can use the existing bound first public key to verify the third signature carried in the public key update transaction. If the verification is successful, the first public key bound to the first object can be updated to the third public key. Subsequently, when any second network layer processes more business transactions initiated by the first object, it can verify the business transactions initiated by the first object through the third public key updated and bound for the first object in the first network layer. This verification process is the same as the process of verifying the business transactions initiated by the first object through the bound first public key.

[0143] The blockchain network in this application may include a first network layer and N second network layers, where N is a positive integer. The first network layer is bound to a first public key of a first object. The N second network layers are used to execute transactions of the first object based on the first public key bound in the first network layer. Any second network layer can receive a business transaction initiated by the first object. The business transaction carries a second public key passed in by the first object, as well as proof information for binding the passed second public key in the first network layer. It also obtains the associated storage information for binding the first public key of the first object in the first network layer. Based on the associated storage information and proof information, it verifies the consistency between the passed second public key and the bound first public key. Therefore, if the passed second public key is consistent with the bound first public key, the business transaction can be executed. Therefore, the method proposed in this application can bind the public key (such as the first public key) of the first object in the first network layer. If the first object needs to change its public key later, it can directly modify the public key bound to it in the first network layer. This allows the first object to maintain only the public key bound to it in the first network layer when maintaining its public key, thus improving the convenience and reliability of the first object managing its public key. Furthermore, when the second network layer receives a transaction initiated by the first object (such as an object transaction), it can first verify the consistency between the public key (such as the second public key) passed by the first object and the public key bound to the first object in the first network layer (such as the first public key). Only when the passed public key is verified to be consistent with the bound public key will the transaction initiated by the first object be executed. In other words, each second network layer relies on the public key bound to the first object in the first network layer when executing a transaction initiated by the first object. This allows each second network layer to rely on the public key bound to the first object in the first network layer, achieving uniformity and accuracy in processing transactions initiated by the first object.

[0144] Please see Figure 6 , Figure 6This is a schematic diagram of a public key registration process provided in an embodiment of this application. The user here refers to the first object mentioned above. The operations performed by the first object can be performed through an object client. The key management module can be the aforementioned public key management contract. All operations related to the public key of the bound object performed by the first network layer in this application can be executed by the first network layer calling the deployed public key management contract. Figure 6 As shown, the process may include:

[0145] In step S201, the user can generate a global user identifier (userId) that they need to register in the object client. This global user identifier (userId) can be the object identifier of the first object.

[0146] In step S202, users can also generate the public-private key pair they need to register in the object client.<pk,sk> The pk can refer to the first public key that needs to be registered, and the sk can refer to the first private key corresponding to the first public key.

[0147] In step S203, the user can construct a registration transaction in the object client using the globally generated user identifier userId and the first public key pk.<userId,pk> The registration transaction can be the aforementioned binding transaction.

[0148] In step S204, the user can use the first private key sk corresponding to the first public key in the object client to sign the registration transaction to obtain a signature sign, which can be the second signature mentioned above.

[0149] Step S205: The user can transmit data to the key management module through the object client.<userId,pk> ,sign>, which means transmitting the registration transaction and the signature sign.

[0150] Step S206, the key management module can verify the data transmitted by the user.<userId,pk> The process involves checking whether the userId in the `sign>` field is already in use, i.e., whether the object identifier registered by the first object overlaps with the existing object identifiers of other objects. If they do not overlap, it indicates that the userId is not in use, and the process can continue to execute the following step S207. If they overlap, it indicates that the userId is already in use, and the process does not need to execute the following step S207. A registration failure message can be returned to the user.

[0151] Step S207, the key management module can verify the transmitted <<userId,pk> Does the sign in `sign>` correspond to pk? That is, does it use the transmitted <...<userId,pk> The check determines whether the pk in the `sign>` property can successfully verify the signature `sign`. If the signature `sign` can be successfully verified, it indicates that the transmitted `<`...<userId,pk> The sign in `sign>` corresponds to pk, and we can continue with step S208 below; however, if the signature verification fails, it indicates that the transmitted <<userId,pk> In the case of `sign>`, the `sign` and `pk` do not correspond. In this case, it can be determined that the user registration failed, and a registration failure message can be returned to the user.

[0152] In step S208, the key management module can store key-value pairs.<userId,pk> For example, storing the key-value pair in the state tree of the first network layer.<userId,pk> This achieves the registration of the first public key pk of the first object through the object identifier userId of the first object. The key management module can then execute the following step S209.

[0153] In step S209, the key management module can return a notification message to the user indicating that their registration was successful.

[0154] Through the above process, the first object registers its object public key in the first network layer. Subsequently, the first object only needs to maintain and manage the object public key registered (i.e. bound) in the first network layer, without having to maintain its own object public key in each second network layer. Each second network layer can uniformly rely on the object public key bound to the first object in the same first network layer to verify the business transactions initiated by the first object. Therefore, the accuracy of the execution of the business transactions of the first object by each second network layer is guaranteed.

[0155] Therefore, this application proposes an account abstraction technology across blockchain layer 2 networks based on key-value proofs. The user's key management module is deployed on the blockchain layer 1 network (i.e., the first network layer), while blockchain layer 2 network accounts (i.e., the second network layer) all rely on the public key bound to the user in the key management module to verify transactions initiated by the user. Specifically, key-value proofs allow blockchain layer 2 network accounts to reliably obtain the public key in the key management module located on the blockchain layer 1 network. Therefore, the user only needs to initiate a transaction to update the public key stored and bound in the key management module (such as a public key update transaction) to achieve atomic synchronous updates of the account public key across blockchain layer 2 networks (i.e., efficiently updating one's own public and private keys in multiple second network layers in one step). This ensures that no updates to the user's public and private keys in each second network layer are missed, greatly improving the user experience, reducing the cost of updating the user's public and private keys, and making the process of updating the user's public and private keys more secure.

[0156] Please see Figure 7 , Figure 7 This is a schematic diagram illustrating a transaction execution process in a second network layer, as provided in an embodiment of this application. The user here refers to the aforementioned first object, and the operations performed by the user can be executed through an object client. The second network layer here can be any second network layer in a blockchain network. Figure 7 As shown, the process may include:

[0157] The following steps S301 to S305 describe the process of constructing a blockchain transaction in the second network layer by the user terminal. The constructed blockchain transaction can be a business transaction initiated by the first object to any second network layer, as described below.

[0158] In step S301, the user can obtain the known binding public-private key pair in the object client.<pk1,sk1> The public and private key pair are bound together.<pk1,sk1> It can refer to the first public key that the first object is bound to in the first network layer and the first private key corresponding to the first public key.

[0159] In step S302, the user can construct (i.e. generate) a transaction tx through the object client. The constructed transaction tx can be a business transaction initiated by the first object mentioned above.

[0160] In step S303, the user can sign the transaction tx in the object client using the private key sk1 obtained above to generate the signature sign of the transaction tx. The signature sign here can be the first signature mentioned above.

[0161] In step S304, the user can query the key-value proof (proof) from the first network layer through the object client. The key-value proof (proof) can be the Merkle proof information of the first public key bound to the first object in the first network layer, which is also the proof information of the second public key mentioned above.

[0162] In step S305, the user can trigger a transaction to the second network layer in the object client. The triggered transaction includes the aforementioned transaction tx, as well as the signature sign, pk1 (which can be referred to as the aforementioned second public key), and the proof (i.e. proof information) carried by the transaction tx.

[0163] Steps S306 to S315 below describe the process by which the second network layer verifies and executes the user-initiated transaction tx, as described below.

[0164] In step S306, the second network layer can read the user identifier userId stored by itself for the user. The user identifier userId is also the object identifier stored by the second network layer for the first object.

[0165] Step S307: The second network layer reads the contract address vault of the key management module (i.e., the public key management contract) stored within itself.

[0166] In step S308, the second network layer can query the first network layer for the root of the state tree of the first network layer's state tree (which can be simply referred to as the state root).

[0167] In step S309, the first network layer can return the queried state root to the second network layer.

[0168] In step S310, the second network layer can reconstruct the Merkle tree of the first network layer using the obtained user identifier userId, the pk1 carried by the transaction tx, the obtained contract address vault, and the proof carried by the transaction tx, to obtain the reconstructed state tree root (i.e. the reconstructed state tree root mentioned above).

[0169] In step S311, the second network layer can verify whether the reconstructed state tree root is equal to (i.e., whether it is consistent with) the state tree root queried from the first network layer. If they are equal, the following step S312 can be executed. If they are not equal, it indicates that the transaction tx initiated by the user is invalid, and a prompt message indicating that the transaction tx initiated by the user is invalid can be returned to the object client.

[0170] In step S312, the second network layer can confirm that the public key corresponding to the user identifier userId stored in the key management module of the first network layer is pk1 carried by transaction tx, that is, the pk1 carried by transaction tx has been successfully verified.

[0171] In step S313, the second network layer can verify the signature (i.e., the first signature) carried by the transaction tx by verifying the successfully verified pk1.

[0172] In step S314, the second network layer can execute the user-initiated transaction tx after the signature sign is successfully verified (i.e., the signature verification is successful).

[0173] In step S315, after successfully executing the transaction tx, the second network layer can return a message indicating that the transaction tx was successfully executed to the user (i.e., to the object client).

[0174] Through the above process, the second network layer relies on the public key bound to the user in the first network layer to execute the transaction initiated by the user. This allows the user to execute transactions in the blockchain network simply by maintaining the public key bound to them in the first network layer.

[0175] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a transaction processing device for a blockchain network provided in an embodiment of this application. The blockchain network may include a first network layer and N second network layers, where N is a positive integer. The first network layer is bound to a first public key of a first object. The N second network layers are used to execute transactions of the first object based on the first public key bound to the first network layer. This transaction processing device is applied to any of the second network layers. Figure 8 As shown, the transaction processing device 80 of the blockchain network may include: a receiving module 801, an acquisition module 802, a verification module 803, and an execution module 804.

[0176] The receiving module 801 is used to receive a business transaction initiated by the first object; the business transaction carries the second public key passed in by the first object, and the proof information of binding the passed second public key in the first network layer;

[0177] The acquisition module 802 is used to acquire the associated storage information of the first public key of the first object bound in the first network layer;

[0178] The verification module 803 is used to verify the consistency between the incoming second public key and the bound first public key based on the associated storage information and the proof information;

[0179] The execution module 804 is used to execute a business transaction if the passed-in second public key matches the bound first public key.

[0180] Optionally, the first public key is bound to the state tree of the first network layer; the acquisition module 802 acquires the associated storage information of the first object's first public key bound in the first network layer in the following ways:

[0181] Query the root of the state tree in the state tree of the first network layer;

[0182] Obtain the target path information from the first public key bound to the first object in the state tree of the first network layer to the root of the state tree;

[0183] The root and target path information of the queried state tree are identified as associated storage information.

[0184] Optionally, the proof information is the Merkel proof information of the second public key in the state tree of the first network layer; the verification module 803 verifies the consistency between the incoming second public key and the bound first public key based on the associated storage information and the proof information, including the following methods:

[0185] Based on the second public key, target path information, and proof information, the state tree of the first network layer is reconstructed to generate the root of the reconstructed state tree of the first network layer.

[0186] Based on the reconstructed state tree root and the queried state tree root, the consistency between the incoming second public key and the bound first public key is verified.

[0187] Optionally, the verification module 803 verifies the consistency between the incoming second public key and the bound first public key based on the reconstructed state tree root and the queried state tree root, including the following methods:

[0188] Compare the reconstructed state tree root with the queried state tree root;

[0189] If the reconstructed state tree root is equal to the queried state tree root, then it is determined that the second public key passed in is consistent with the first public key bound to it.

[0190] If the reconstructed state tree root is different from the queried state tree root, then it is determined that the second public key passed in is inconsistent with the first public key bound to it.

[0191] Optionally, a public key management contract is deployed in the first network layer. The first public key is stored in the state tree of the first network layer based on the public key management contract. Both the first public key and the public key management contract correspond to state nodes in the state tree of the first network layer.

[0192] In the state tree of the first network layer, the path information from the state node of the first public key to the state node of the public key management contract includes the object identifier of the first object, and the path information from the state node of the public key management contract to the root of the state tree includes the contract address of the public key management contract.

[0193] The target path information includes the object identifier stored for the first object in any network layer, and the contract address stored for the public key management contract.

[0194] Optionally, the business transaction also carries a first signature, which is obtained by signing the business transaction using the first private key corresponding to the first public key;

[0195] The execution module 804 executes business transactions in the following ways:

[0196] The first signature is verified using the passed-in second public key;

[0197] If the first signature is successfully verified, the business transaction is executed in any second network layer.

[0198] Optionally, the business transaction is a resource transfer transaction, which is used to transfer the target resource of the first object to the second object in any second network layer; the execution module 804 executes the business transaction in any second network layer in the following ways:

[0199] Obtain the target resource of the first object from its blockchain address in any second network layer;

[0200] The acquired target resources are transferred to the blockchain address of the second object in any second network layer.

[0201] Optionally, the first signature is obtained by encrypting the transaction hash of the business transaction using the first private key; the execution module 804 verifies the first signature using the passed-in second public key, including:

[0202] The first signature is decrypted using the passed-in second public key to obtain the decryption hash;

[0203] Perform hash calculations on the business transactions to obtain the calculated hash of the business transactions;

[0204] If the calculated hash is equal to the decrypted hash, then the first signature verification is successful.

[0205] If the calculated hash and the decrypted hash are not equal, then the verification of the first signature has failed.

[0206] Optionally, the first network layer is used to receive a binding transaction initiated by the first object. The binding transaction includes the object identifier of the first object and the first public key. The binding transaction carries a second signature, which is obtained by signing the binding transaction using the first private key corresponding to the first public key.

[0207] The first network layer is used to verify the second signature using the first public key in the binding transaction, and after the second signature is successfully verified, it binds the first public key to the first object in the state tree of the first network layer based on the object identifier of the first object.

[0208] Optionally, the first network layer is used to receive a public key update transaction initiated by the first object. The public key update transaction contains the third public key to be updated. The public key update transaction carries a third signature, which is obtained by signing the public key update transaction using the first private key corresponding to the first public key.

[0209] The first network layer is used to verify the third signature based on the first public key bound to the first object in the state tree, and to update the first public key bound to the first object in the state tree of the first network layer to the third public key after the third signature is successfully verified.

[0210] Optionally, the business transaction is sent from the object client of the first object to any second network layer; the transaction processing apparatus further includes a prompting module 805, which is used for:

[0211] If the passed-in second public key matches the bound first public key, then after executing the business transaction, the execution result of the business transaction is obtained and returned to the object client; and,

[0212] If the second public key passed in does not match the first public key bound to it, an invalid business transaction message will be generated and returned to the client.

[0213] According to one embodiment of this application, Figure 3 The steps involved in the transaction processing method of the blockchain network shown can be derived from... Figure 8 The transaction processing unit 80 of the blockchain network shown is used to execute the transactions. For example, Figure 3 Step S101 shown can be performed by Figure 8 The receiving module 801 in the middle performs the operation. Figure 3 Step S102 shown can be performed by Figure 8 The acquisition module 802 in the middle is used to execute; Figure 3 Step S103 shown can be performed by Figure 8 The verification module 803 in the middle is used to execute it. Figure 3 Step S104 shown can be performed by Figure 8 The execution module 804 in the middle is used to execute it.

[0214] The blockchain network in this application may include a first network layer and N second network layers, where N is a positive integer. The first network layer is bound to a first public key of a first object. The N second network layers are used to execute transactions of the first object based on the first public key bound in the first network layer. Any second network layer can receive a business transaction initiated by the first object. The business transaction carries a second public key passed in by the first object, as well as proof information for binding the passed second public key in the first network layer. It also obtains the associated storage information for binding the first public key of the first object in the first network layer. Based on the associated storage information and proof information, it verifies the consistency between the passed second public key and the bound first public key. Therefore, if the passed second public key is consistent with the bound first public key, the business transaction can be executed. Therefore, the device proposed in this application can bind the public key (such as the first public key) of the first object in the first network layer. If the first object needs to change its public key later, it can directly modify the public key bound to it in the first network layer. This allows the first object to maintain only the public key bound to it in the first network layer when maintaining its public key, thus improving the convenience and reliability of the first object managing its public key. Furthermore, when the second network layer receives a transaction initiated by the first object (such as an object transaction), it can first verify the consistency between the public key (such as the second public key) passed by the first object and the public key bound to the first object in the first network layer (such as the first public key). Only when the passed public key is verified to be consistent with the bound public key will the transaction initiated by the first object be executed. In other words, each second network layer relies on the public key bound to the first object in the first network layer when executing a transaction initiated by the first object. This allows each second network layer to rely on the public key bound to the first object in the first network layer, achieving uniformity and accuracy in processing transactions initiated by the first object.

[0215] According to one embodiment of this application, Figure 8 The various modules in the transaction processing device 80 of the blockchain network shown can be individually or entirely merged into one or more units, or one or more of these units can be further divided into multiple functionally smaller sub-units to achieve the same operation without affecting the technical effects of the embodiments of this application. The above modules are based on logical functional division; in practical applications, the function of one module can be implemented by multiple units, or the function of multiple modules can be implemented by one unit. In other embodiments of this application, the transaction processing device 80 of the blockchain network may also include other units; in practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0216] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0217] According to one embodiment of this application, a computer program capable of executing the steps involved in the corresponding methods shown in the various embodiments of this application can be run on a general-purpose computer device (which may include processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM)) to construct a system as described in the embodiments of this application. Figure 8 The blockchain network transaction processing apparatus 80 shown herein. The aforementioned computer program can be recorded on a computer-readable recording medium, and can be loaded into the aforementioned computer device via the computer-readable recording medium and run therein.

[0218] Please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 9 As shown, the computer device 1000 may include a processor 1001, a network interface 1004, and a memory 1005. In some embodiments, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 9 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

[0219] exist Figure 9In the computer device 1000 shown, the network interface 1004 provides network communication functions; while the user interface 1003 is mainly used to provide an input interface for the user; the blockchain network in this application may include a first network layer and N second network layers, where N is a positive integer. The first network layer is bound to the first public key of the first object, and the N second network layers are used to execute transactions of the first object based on the first public key bound to the first network layer. The processor 1001 can be applied to any of the second network layers, and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0220] Receive a business transaction initiated by the first object; the business transaction carries the second public key passed in by the first object, and the proof information of binding the passed second public key in the first network layer;

[0221] Obtain the first public key of the first object and the associated storage information bound in the first network layer;

[0222] Based on the associated storage information and proof information, the consistency between the incoming second public key and the bound first public key is verified;

[0223] If the second public key passed in matches the first public key bound to it, the business transaction will be executed.

[0224] In one feasible implementation, the first public key is bound to the state tree of the first network layer; the processor 1001 can also be used to call the device control application stored in the memory 1005 to achieve:

[0225] Query the root of the state tree in the state tree of the first network layer;

[0226] Obtain the target path information from the first public key bound to the first object in the state tree of the first network layer to the root of the state tree;

[0227] The root and target path information of the queried state tree are identified as associated storage information.

[0228] In one feasible implementation, the proof information is the Merkel proof information of the second public key in the state tree of the first network layer; the processor 1001 can also be used to call the device control application stored in the memory 1005 to achieve:

[0229] Based on the second public key, target path information, and proof information, the state tree of the first network layer is reconstructed to generate the root of the reconstructed state tree of the first network layer.

[0230] Based on the reconstructed state tree root and the queried state tree root, the consistency between the incoming second public key and the bound first public key is verified.

[0231] In one feasible implementation, the processor 1001 can also be used to invoke a device control application stored in the memory 1005 to achieve:

[0232] Compare the reconstructed state tree root with the queried state tree root;

[0233] If the reconstructed state tree root is equal to the queried state tree root, then it is determined that the second public key passed in is consistent with the first public key bound to it.

[0234] If the reconstructed state tree root is different from the queried state tree root, then it is determined that the second public key passed in is inconsistent with the first public key bound to it.

[0235] In one feasible implementation, a public key management contract is deployed in the first network layer. The first public key is stored in the state tree of the first network layer based on the public key management contract. Both the first public key and the public key management contract correspond to state nodes in the state tree of the first network layer.

[0236] In the state tree of the first network layer, the path information from the state node of the first public key to the state node of the public key management contract includes the object identifier of the first object, and the path information from the state node of the public key management contract to the root of the state tree includes the contract address of the public key management contract.

[0237] The target path information includes the object identifier stored for the first object in any network layer, and the contract address stored for the public key management contract.

[0238] In one feasible implementation, the business transaction also carries a first signature, which is obtained by signing the business transaction using the first private key corresponding to the first public key.

[0239] Processor 1001 can also be used to call device control applications stored in memory 1005 to achieve:

[0240] The first signature is verified using the passed-in second public key;

[0241] If the first signature is successfully verified, the business transaction is executed in any second network layer.

[0242] In one feasible implementation, the business transaction is a resource transfer transaction, which is used to transfer a target resource of a first object to a second object in any second network layer; the processor 1001 can also be used to call a device control application stored in the memory 1005 to achieve:

[0243] Obtain the target resource of the first object from its blockchain address in any second network layer;

[0244] The acquired target resources are transferred to the blockchain address of the second object in any second network layer.

[0245] In one feasible implementation, the first signature is obtained by encrypting the transaction hash of the business transaction using a first private key; the processor 1001 can also be used to call the device control application stored in the memory 1005 to achieve:

[0246] The first signature is decrypted using the passed-in second public key to obtain the decryption hash;

[0247] Perform hash calculations on the business transactions to obtain the calculated hash of the business transactions;

[0248] If the calculated hash is equal to the decrypted hash, then the first signature verification is successful.

[0249] If the calculated hash and the decrypted hash are not equal, then the verification of the first signature has failed.

[0250] In one feasible implementation, the first network layer is used to receive a binding transaction initiated by the first object. The binding transaction includes the object identifier of the first object and the first public key. The binding transaction carries a second signature, which is obtained by signing the binding transaction using the first private key corresponding to the first public key.

[0251] The first network layer is used to verify the second signature using the first public key in the binding transaction, and after the second signature is successfully verified, it binds the first public key to the first object in the state tree of the first network layer based on the object identifier of the first object.

[0252] In one feasible implementation, the first network layer is used to receive a public key update transaction initiated by the first object. The public key update transaction contains a third public key to be updated to. The public key update transaction carries a third signature, which is obtained by signing the public key update transaction with the first private key corresponding to the first public key.

[0253] The first network layer is used to verify the third signature based on the first public key bound to the first object in the state tree, and to update the first public key bound to the first object in the state tree of the first network layer to the third public key after the third signature is successfully verified.

[0254] In one feasible implementation, the business transaction is sent by the object client of the first object to any second network layer; the processor 1001 can also be used to call the device control application stored in the memory 1005 to achieve:

[0255] If the passed-in second public key matches the bound first public key, then after executing the business transaction, the execution result of the business transaction is obtained and returned to the object client; and,

[0256] If the second public key passed in does not match the first public key bound to it, an invalid business transaction message will be generated and returned to the client.

[0257] It should be understood that the computer device 1000 described in the embodiments of this application can execute the transaction processing method of the blockchain network described in the embodiments of this application, and can also execute the methods described above. Figure 8 The description of the transaction processing device 80 of the blockchain network in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0258] Furthermore, it should be noted that this application also provides a computer-readable storage medium storing a computer program. When a processor executes this computer program, it can perform the transaction processing methods for the blockchain network described in the various embodiments of this application. Therefore, these methods will not be repeated here. Additionally, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the embodiments of the computer storage medium involved in this application, please refer to the description of the method embodiments of this application.

[0259] As an example, the aforementioned computer program can be deployed and executed on a single computer device, or deployed and executed on multiple computer devices located in one location, or executed on multiple computer devices distributed across multiple locations and interconnected via a communication network. These multiple computer devices distributed across multiple locations and interconnected via a communication network can form a blockchain network.

[0260] The aforementioned computer-readable storage medium can be an internal storage unit of the computer device, such as a hard drive or memory. It can also be an external storage device, such as a plug-in hard drive, smart media card (SMC), secure digital card (SD) card, or flash card. Furthermore, the computer-readable storage medium can include both internal and external storage units of the computer device. This computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. It can also be used to temporarily store data that has been output or will be output.

[0261] This application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the transaction processing method for the blockchain network described in the embodiments of this application; therefore, it will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the embodiments of the computer-readable storage medium involved in this application, please refer to the description of the method embodiments of this application.

[0262] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0263] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0264] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A transaction processing method for a blockchain network, characterized in that, The blockchain network includes a first network layer and N second network layers, where N is a positive integer. The first network layer is bound to a first public key of a first object. The N second network layers are used to execute transactions of the first object based on the first public key bound to the first network layer. The method is applied to any of the second network layers. The method includes: Receive a business transaction initiated by the first object; the business transaction carries a second public key passed in by the first object, and proof information of binding the passed second public key in the first network layer; Obtain the associated storage information of the first public key of the first object bound in the first network layer; Based on the associated storage information and the proof information, the consistency between the incoming second public key and the bound first public key is verified; If the second public key passed in matches the first public key bound to it, then the business transaction is executed.

2. The method as described in claim 1, characterized in that, The first public key is bound to the state tree of the first network layer; The step of obtaining the association storage information of the first public key of the first object bound in the first network layer includes: Query the root of the state tree in the state tree of the first network layer; Obtain the target path information from the first public key bound to the first object in the state tree of the first network layer to the root of the state tree; The queried state tree root and the target path information are determined as the associated storage information.

3. The method as described in claim 2, characterized in that, The proof information is the Merkel proof information of the second public key in the state tree of the first network layer; the verification of the consistency between the incoming second public key and the bound first public key based on the associated storage information and the proof information includes: Based on the second public key, the target path information, and the proof information, the state tree of the first network layer is reconstructed to generate the reconstructed state tree root of the first network layer. Based on the reconstructed state tree root and the queried state tree root, the consistency between the incoming second public key and the bound first public key is verified.

4. The method as described in claim 3, characterized in that, The verification of the consistency between the input second public key and the bound first public key based on the reconstructed state tree root and the queried state tree root includes: The reconstructed state tree root and the queried state tree root are compared; If the reconstructed state tree root is equal to the queried state tree root, then it is determined that the passed second public key is consistent with the bound first public key; If the reconstructed state tree root is not equal to the queried state tree root, then it is determined that the passed-in second public key is inconsistent with the bound first public key.

5. The method as described in claim 2, characterized in that, A public key management contract is deployed in the first network layer. The first public key is stored in the state tree of the first network layer based on the public key management contract. Both the first public key and the public key management contract correspond to state nodes in the state tree of the first network layer. In the state tree of the first network layer, the path information from the state node of the first public key to the state node of the public key management contract includes the object identifier of the first object, and the path information from the state node of the public key management contract to the root of the state tree includes the contract address of the public key management contract. The target path information includes the object identifier stored for the first object in any of the network layers, and the contract address stored for the public key management contract.

6. The method as described in claim 1, characterized in that, The business transaction also carries a first signature, which is obtained by signing the business transaction using the first private key corresponding to the first public key. The execution of the business transaction includes: The first signature is verified using the second public key that was passed in. If the first signature is successfully verified, the business transaction is executed in any of the second network layers.

7. The method as described in claim 6, characterized in that, The business transaction is a resource transfer transaction, which is used to transfer the target resource of the first object to the second object in any second network layer; the execution of the business transaction in any second network layer includes: Obtain the target resource of the first object from the blockchain address of the first object in any of the second network layers; The acquired target resource is transferred to the blockchain address of the second object in any of the second network layers.

8. The method as described in claim 6, characterized in that, The first signature is obtained by encrypting the transaction hash of the business transaction using the first private key; the verification process of the first signature using the input second public key includes: The first signature is decrypted using the passed-in second public key to obtain the decryption hash; Perform a hash calculation on the business transaction to obtain the calculated hash of the business transaction; If the calculated hash is equal to the decrypted hash, then the verification of the first signature is successful. If the calculated hash is not equal to the decrypted hash, then the verification of the first signature is determined to have failed.

9. The method as described in claim 1, characterized in that, The first network layer is used to receive a binding transaction initiated by the first object. The binding transaction includes the object identifier of the first object and the first public key. The binding transaction carries a second signature, which is obtained by signing the binding transaction using the first private key corresponding to the first public key. The first network layer is used to verify the second signature using the first public key in the binding transaction, and after the second signature is successfully verified, it binds the first public key to the first object in the state tree of the first network layer based on the object identifier of the first object.

10. The method as described in claim 1, characterized in that, The first network layer is used to receive a public key update transaction initiated by the first object. The public key update transaction contains a third public key to be updated to. The public key update transaction carries a third signature. The third signature is obtained by signing the public key update transaction using the first private key corresponding to the first public key. The first network layer is used to verify the third signature based on the first public key bound to the first object in the state tree, and is used to update the first public key bound to the first object in the state tree of the first network layer to the third public key after the third signature is successfully verified.

11. The method as described in claim 1, characterized in that, The business transaction is sent by the object client of the first object to any of the second network layers; the method further includes: If the second public key passed in matches the first public key bound to it, then after executing the business transaction, the execution result of the business transaction is obtained, and the execution result is returned to the object client; and, If the second public key passed in does not match the first public key bound to it, an invalid business transaction message is generated and returned to the object client.

12. A transaction processing device for a blockchain network, characterized in that, The blockchain network includes a first network layer and N second network layers, where N is a positive integer. The first network layer is bound to a first public key of a first object. The N second network layers are used to execute transactions of the first object based on the first public key bound to the first network layer. The device is applied to any of the second network layers. The device includes: A receiving module is used to receive a business transaction initiated by the first object; the business transaction carries a second public key passed in by the first object, and proof information of binding the passed second public key in the first network layer; The acquisition module is used to acquire the associated storage information of the first public key of the first object being bound in the first network layer; The verification module is used to verify the consistency between the incoming second public key and the bound first public key based on the associated storage information and the proof information; An execution module is used to execute the business transaction if the passed-in second public key matches the bound first public key.

13. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-11.

14. A computer device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the method according to any one of claims 1-11.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and executed as described in any one of claims 1-11.

Images