Data processing method and device based on block chain, equipment and medium

Abstract

The invention provides a data processing method and device based on a block chain, equipment and a medium, and the method comprises the steps: when a resource service device obtains a space management request associated with N contract addresses, sending the space management request to M approval terminals for approval signature, and obtaining approval signature information for first signature content; based on obtained approval signature information returned by M approval terminals, a first approval signature list is constructed, and when a first signature transaction is constructed based on a first operation private key of an operation object i, first signature content, a first Merkel path pointing to a Merkel tree root from a contract address i and the first approval signature list, the first signature transaction is signed to the Merkel tree root from the contract address i; and sending the first signature transaction to the first consensus node, so that the first consensus node calls the resource management contract i to execute a business modification event after performing transaction signature verification and transaction verification on the first signature transaction. The address management efficiency can be improved for different addresses in the service space.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a blockchain-based data processing method, apparatus, device, and medium. Background Art

[0002] Currently, multiple resource management contracts (for example, 3 resource management contracts) can be deployed on the blockchain, and each resource management contract can correspond to a contract address.

[0003] Based on this, the inventors found in practice that in the existing signature approval scheme, if the resource service background needs to sign and approve the operation triggered by a certain approval administrator (for example, management object U0) for these contract addresses (that is, three contract addresses, for example, contract address D1, contract address D2, and contract address D3), the resource service background will successively receive three signature approval requests initiated by the management object U0 for different contract addresses, for example, signature approval request Q1 initiated for contract address D1, signature approval request Q2 initiated for contract address D2, and signature approval request Q3 initiated for contract address D3. At this time, the signature content carried in the signature approval request Q1 will clearly specify the contract address D1, the other signature content carried in the signature approval request Q2 will clearly specify the contract address D2, and the other signature content carried in the signature approval request Q3 will clearly specify the contract address D3. This means that for any one of the multiple approval objects (for example, approval object Ua) currently participating in the signature approval process (for example, approval object Ua and approval object Ub), three signature approval requests with different signature contents will be received in succession. Therefore, for any one of the approval objects (for example, approval object Ua) currently participating in the approval signature process, three approval signatures need to be performed for each of the three different signature contents. This means that once a large number of contract addresses require address management, when the existing approval signature solution is used to separately approve the signature contents directly carrying each different contract address, a longer approval signature time will be required, thereby reducing the efficiency of address management for different contract addresses. Summary of the Invention

[0004] The embodiments of the present application provide a blockchain-based data processing method, apparatus, device, and medium. By adopting the present application, batch management of different contract addresses in the business space can be achieved based on the business space, thereby improving the efficiency of address management of different contract addresses.

[0005] On one hand, an embodiment of the present application provides a data processing method based on blockchain, which is executed by a resource service device in a resource business service system. The business space of the resource business service system includes N contract addresses, where N is a positive integer greater than 1. The N contract addresses include a contract address i. The operation object corresponding to the contract address i is the operation object i. The resource management contract corresponding to the contract address i is the resource management contract i on the blockchain, where i is a positive integer less than or equal to N. The method includes:

[0006] Obtain a space management request associated with N contract addresses; the first signature carried in the space management request includes the Merkle tree root associated with the N contract addresses and the modification business event triggered for the N contract addresses;

[0007] Sending a space management request to M approval terminals associated with the business space, so that the M approval terminals perform approval signatures on the first signature content to obtain approval signature information for the first signature content; M is a positive integer greater than 1;

[0008] Obtain the approval signature information returned by the M approval terminals. Based on the obtained approval signature information, construct the first approval signature list associated with the M approval terminals, and determine the first Merkle path from the contract address i to the Merkle tree root.

[0009] Obtain the first operation private key of the operation object i. When the first signature transaction is constructed based on the first operation private key, the first signature content, the first Merkle path, and the first approval signature list, the first signature transaction is sent to the first consensus node running the resource management contract i. The first consensus node is used to verify the first signature transaction using the first operation public key corresponding to the first operation private key. When the transaction verification is successful, the first signature transaction is verified through the resource management contract i. When the transaction verification is successful, the resource management contract i is called to execute the modification business event. The transaction verification includes root verification of the Merkle tree root based on the first Merkle path and multi-signature verification of the first approval signature list.

[0010] On one hand, an embodiment of the present application provides a data processing method based on blockchain, the method being executed by a first consensus node, the first consensus node being a consensus node on a blockchain associated with a contract address i, the contract address i being included in N contract addresses, the N contract addresses being deployed in a business space of a resource business service system, N being a positive integer greater than 1, the operation object corresponding to the contract address i being operation object i, the resource management contract corresponding to the contract address i being resource management contract i on the blockchain, i being a positive integer less than or equal to N, the method comprising:

[0011] Receive a first signature transaction sent by a resource service device in a resource business service system; the first signature transaction is constructed by the resource service device based on the first operation private key, the first signature content, the first Merkle path, and the first approval signature list of the operation object i; the first signature content is determined by the resource service device based on the acquired space management request associated with N contract addresses, and the first signature content includes the Merkle tree root associated with the N contract addresses and the modification business event triggered for the N contract addresses; the first Merkle path refers to the path from the contract address i to the Merkle tree root; the space management request is used to instruct the M approval terminals associated with the business space to approve and sign the first signature content, and obtain the approval signature information for the first signature content; the first approval signature list is constructed by the resource service device based on the approval signature information returned by the M approval terminals;

[0012] Verify the first signature transaction using the first operation public key corresponding to the first operation private key to obtain a transaction verification result;

[0013] When the transaction verification result indicates that the transaction verification is successful, the resource management contract i is used to perform transaction verification on the first signature transaction to obtain a transaction verification result; the transaction verification includes performing root verification on the Merkle tree root based on the first Merkle path and performing multi-signature verification on the first approval signature list;

[0014] When the transaction verification result indicates that the transaction verification is successful, the resource management contract i is called to execute the modification business event.

[0015] In one aspect, an embodiment of the present application provides a data processing device based on blockchain. The device runs on a resource service device in a resource business service system. The business space of the resource business service system includes N contract addresses, where N is a positive integer greater than 1. The N contract addresses include a contract address i. The operation object corresponding to the contract address i is the operation object i. The resource management contract corresponding to the contract address i is the resource management contract i on the blockchain, where i is a positive integer less than or equal to N. The device includes:

[0016] A management request acquisition module is used to obtain space management requests associated with N contract addresses. The first signature content carried in the space management request includes the Merkle tree root associated with the N contract addresses and the modification business event triggered for the N contract addresses.

[0017] A management request sending module, configured to send a space management request to M approval terminals associated with the business space, so that the M approval terminals perform approval signatures on the first signature content to obtain approval signature information for the first signature content; M is a positive integer greater than 1;

[0018] The signature list construction module is used to obtain the approval signature information returned by the M approval terminals. Based on the obtained approval signature information, it constructs the first approval signature list associated with the M approval terminals and determines the first Merkle path from the contract address i to the Merkle tree root.

[0019] The signature transaction sending module is used to obtain the first operation private key of the operation object i. When the first signature transaction is constructed based on the first operation private key, the first signature content, the first Merkle path and the first approval signature list, the first signature transaction is sent to the first consensus node running the resource management contract i; the first consensus node is used to verify the first signature transaction through the first operation public key corresponding to the first operation private key, and when the transaction verification is successful, the first signature transaction is verified through the resource management contract i, and when the transaction verification is successful, the resource management contract i is called to execute the modification business event; the transaction verification includes root verification of the Merkle tree root based on the first Merkle path and multi-signature verification of the first approval signature list.

[0020] On one hand, an embodiment of the present application provides a data processing device based on blockchain. The device runs on a first consensus node. The first consensus node is a consensus node on the blockchain associated with a contract address i. The contract address i is included in N contract addresses. The N contract addresses are deployed in the business space of a resource business service system. N is a positive integer greater than 1. The operation object corresponding to the contract address i is operation object i. The resource management contract corresponding to the contract address i is resource management contract i on the blockchain. i is a positive integer less than or equal to N. The device includes:

[0021] A transaction receiving module is used to receive a first signature transaction sent by a resource service device in a resource business service system; the first signature transaction is constructed by the resource service device based on the first operation private key, first signature content, first Merkle path and first approval signature list of the operation object i; the first signature content is determined by the resource service device based on the acquired space management request associated with N contract addresses, and the first signature content includes the Merkle tree root associated with the N contract addresses and the modification business event triggered for the N contract addresses; the first Merkle path refers to the path from the contract address i to the Merkle tree root; the space management request is used to instruct the M approval terminals associated with the business space to approve and sign the first signature content to obtain the approval signature information for the first signature content; the first approval signature list is constructed by the resource service device based on the approval signature information returned by the M approval terminals;

[0022] A transaction signature verification module, configured to verify the first signed transaction using the first operation public key corresponding to the first operation private key, and obtain a transaction signature verification result;

[0023] The transaction verification module is used to verify the first signed transaction through the resource management contract i when the transaction verification result indicates that the transaction verification is successful, and obtain the transaction verification result; the transaction verification includes root verification of the Merkle tree root based on the first Merkle path and multi-signature verification of the first approval signature list;

[0024] The event execution module is used to call the resource management contract i to execute the modification business event when the transaction verification result indicates that the transaction verification is successful.

[0025] In one aspect, an embodiment of the present application provides a computer device, including a memory and a processor, wherein the memory is connected to the processor, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method provided in the above aspect of the embodiment of the present application.

[0026] On one hand, an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. The computer program is suitable for being loaded and executed by a processor, so that a computer device with a processor executes the method provided in the above aspect of the embodiment of the present application.

[0027] According to one aspect of the present application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in the above aspect.

[0028] The resource service device involved in the embodiment of the present application is a computer device in a resource business service system. The resource business service system here may also include multiple approval terminals (i.e., M approval terminals, M is a positive integer greater than 1) for centrally managing a certain space (i.e., business space). Multiple contract addresses (i.e., N contract addresses, N is a positive integer greater than 1) are recorded in the business space. Each contract address here corresponds to a resource management contract on a certain blockchain. For ease of understanding, here we take contract address i among the N contract addresses as an example. The resource management contract corresponding to the contract address i is the resource management contract i on the blockchain, and the operation object corresponding to the contract address i is the operation object i. It should be understood that the embodiments of the present application can be based on the spatial concept of business space, so that when the approval object corresponding to each approval terminal approves and signs the same signature content (that is, the first signature content), it only needs to approve and sign the same signature content (that is, the Merkle root directly carried in the first signature content) once. This can enable each approval object to indirectly approve and sign multiple different contract addresses associated with the Merkle root in the same business space, without the need for each approval object to directly approve and sign these different contract addresses separately. This means that the embodiments of the present application directly use the Merkle root in the first signature content instead of directly using N contract addresses, so there is no need to approve and sign each of the N contract addresses separately. In this way, the efficiency of approving and signing different contract addresses in the same business space can be effectively improved. In addition, it can be understood that after collecting the approval signature information of these approval terminals, the resource service background can quickly construct a first approval signature list for multi-signature verification, and then can use the operation private key of the operation object (for example, the above-mentioned operation object i) corresponding to the corresponding resource management contract (for example, the above-mentioned resource management contract i) to construct a signature transaction to be submitted to the blockchain (for example, the above-mentioned first signature transaction). This means that for the consensus node (that is, the above-mentioned first consensus node) running the corresponding resource management contract (for example, the above-mentioned resource management contract i) on a certain blockchain, it can quickly and accurately call the corresponding resource management contract (for example, the above-mentioned resource management contract i) after transaction verification (for example, root verification and multi-signature verification) to execute the modification business event for the corresponding contract address (that is, contract address i) among the N contract addresses, thereby improving the efficiency of address management of different contract addresses in the same business space. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0030] Figure 1 This is a schematic diagram of a system architecture provided by an embodiment of the present application;

[0031] Figure 2 This is a schematic diagram of a data interaction scenario provided by an embodiment of the present application;

[0032] Figure 3 This is a data processing method based on blockchain provided by an embodiment of the present application;

[0033] Figure 4 This is a schematic diagram of a scenario in which a resource business service system provides a visual business service page to a management terminal, as provided in an embodiment of the present application;

[0034] Figure 5 This is a schematic diagram of a scenario for determining a spatial operation sequence number provided by an embodiment of the present application;

[0035] Figure 6 This is a schematic diagram of a scenario for determining a Merkle tree root provided by an embodiment of the present application;

[0036] Figure 7 This is a schematic diagram of another scenario for determining the root of a Merkle tree provided by an embodiment of the present application;

[0037] Figure 8 This is a schematic diagram of a scenario in which a space management request is sent to approval objects in different approval groups, provided by an embodiment of the present application;

[0038] Figure 9 This is a schematic diagram of a scenario for constructing a signature transaction provided by an embodiment of the present application;

[0039] Figure 10 This is a data processing method based on blockchain provided by an embodiment of the present application;

[0040] Figure 11 This is a schematic diagram of a scenario in which a signed transaction is submitted to a target consensus node on a target chain, provided by an embodiment of the present application;

[0041] Figure 12 This is a data processing method based on blockchain provided by an embodiment of the present application;

[0042] Figure 13This is an interactive sequence diagram of a blockchain-based data processing method provided in an embodiment of the present application;

[0043] Figure 14 This is a schematic diagram of a scenario for submitting a multi-signature transaction provided in an embodiment of the present application;

[0044] Figure 15 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of the present application;

[0045] Figure 16 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of the present application;

[0046] Figure 17 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present application;

[0047] Figure 18 This is a schematic diagram of a blockchain-based data processing system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0048] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0049] 1. Blockchain: Blockchain is a new application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Blockchain is essentially a decentralized database, a series of data blocks generated using cryptographic methods. Each block contains information about a batch of network transactions, used to verify the validity of this information (to prevent counterfeiting) and generate the next block. A blockchain can include the underlying blockchain platform, the platform's product and service layer, and the application service layer. A blockchain consists of a series of blocks that are sequentially generated. Once added to the blockchain, they cannot be removed. Blockchain records the data submitted by the blockchain nodes in the blockchain system.

[0050] It is understood that the blockchains involved in the embodiments of the present application may include at least a first blockchain and a second blockchain. For ease of distinction, the consensus nodes on the first blockchain may be collectively referred to as first consensus nodes, and the consensus nodes on the second blockchain may be collectively referred to as second consensus nodes. At least one of the first blockchain and the second blockchain may be a main chain in a layered chain network in which the layered blockchain resides, or a subchain in the layered chain network. The specific chain types of the first blockchain and the second blockchain are not limited herein.

[0051] 2. Layered blockchain: The layered blockchain refers to a solution further proposed by applying the above-mentioned blockchain to the corresponding industrial architecture. That is, the solution points out that the entire blockchain network can be divided into a consensus network and a witness network, and then the corresponding services can be respectively executed through one or more node devices in the consensus network (i.e., consensus node devices, such as the above-mentioned first consensus node and / or second consensus node) and node devices in the witness network (i.e., business node devices, such as resource service devices). The resource service devices here can be used to execute address management services and asset transfer services. The assets here can include but are not limited to electronic bill assets, virtual digital assets, etc.

[0052] Among them, it can be understood that a core consensus algorithm is run on the node devices deployed in the consensus network (i.e., consensus node devices), through which a block consensus can be performed on a certain block packaged in the consensus network, and then, if the block consensus is successful, the packaged block can be chained to the blockchain maintained by these consensus node devices in the consensus network.

[0053] Among them, the node devices deployed in the witness network (i.e., business node devices) can participate in the clearing and synchronization of data, and complete related specific services based on the business node devices or lightweight nodes (Simplified Payment Verification, referred to as SPV). For example, the specific services here may include but are not limited to address management services for centralized modification operations on different contract addresses in a certain business space.

[0054] In other words, under the layered blockchain architecture involved in the embodiments of the present application, after the consensus node device receives a transaction synchronization request sent by a lightweight node (also referred to as a business node device), the consensus node device can synchronize the transactions that the lightweight node (for example, the corresponding operation service component in the resource service device) has the authority to read to the lightweight node. In other words, for the lightweight node, it can synchronize transaction data related to itself from the consensus node device of the consensus network, but will not synchronize transaction data that is not related to itself, so that the security of on-chain data storage can be ensured.

[0055] Among them, it should be understood that the blockchain system involved in this application can specifically be multiple blockchains under a multi-chain architecture evolved from a layered blockchain network, where the multiple blockchains can include at least a first blockchain and a second blockchain. It should be understood that the resource service device involved in the embodiment of the present application can interact with the first consensus node on the first blockchain and the second consensus node on the second blockchain for data. For example, the resource service device can be used to submit a signed transaction for centralized modification operations for different contract addresses in the business space to the first consensus node, and can also submit another signed transaction for centralized modification operations for different contract addresses in the same business space to the second consensus node. For ease of understanding, in the embodiment of the present application, the signed transaction obtained after the resource service device signs the transaction using the private key of the first operation object (i.e., the first operation private key) is collectively referred to as the first signed transaction, and the signed transaction obtained after the resource service device signs the transaction using the private key of the second operation object (i.e., the second operation private key) is collectively referred to as the second signed transaction. Among them, the first operation object refers to the operator configured for the resource management contract on the first blockchain to sign the transaction, and the second operation object refers to other operators configured for the resource management contract on the second blockchain to sign the transaction.

[0056] The first blockchain and the second blockchain may be of the same or different blockchain types. For example, when the first blockchain and the second blockchain have the same blockchain type, the first blockchain and the second blockchain may be referred to as isomorphic chains, i.e., in this case, the core consensus algorithm employed by the two blockchains may be the same. Alternatively, when the first blockchain and the second blockchain have different blockchain types, the first blockchain and the second blockchain may be referred to as heterogeneous chains, i.e., in this case, the core consensus algorithms employed by the two blockchains are different.

[0057] 3. Resource Management Contract: A smart contract deployed on a blockchain (e.g., the first blockchain and / or the second blockchain described above) that manages and operates assets. Assets here may include, but are not limited to, the aforementioned electronic invoice assets and virtual digital assets. It should be understood that in the embodiments of this application, each of these resource management contracts deployed on the blockchain can be uniquely identified by its corresponding contract address. For each consensus node on the blockchain, when the corresponding resource management contract is running in the virtual machine on each consensus node, the transaction write data and transaction read data of each signed transaction can be read from the contract state data recorded by the resource management contract.

[0058] It is understood that in the embodiment of the present application, the consensus node running the resource management contract can call the corresponding resource management contract to execute each signature transaction in the target block during the process of performing block consensus on a packaged block (i.e., the target block) to obtain the transaction execution results of each signature transaction. It should be understood that the transaction read data of a signature transaction refers to the data read by the consensus node when calling the resource management contract to execute the signature transaction. The transaction write data refers to the data obtained by the consensus node after executing the signature transaction based on the read transaction read data, for example, the transaction execution result of the signature transaction.

[0059] 4. Multi-signature resource management contract. The multi-signature resource management contract here is essentially a resource management contract corresponding to different contract addresses in the above business space. All operations on the resource management contract corresponding to different contract addresses in the business space need to verify the multi-signature passed into the resource management contract for authorization. For example, if there are four approval objects associated with a resource management contract, the approval addresses of these four approval objects (for example, approval object Ua, approval object Ub, approval object Uc, and approval object Ud) are approval address A, approval address B, approval address C, and approval address D respectively. Then, when the signature threshold of the multi-signature is 3, the resource service device used to provide service services for these resource management contracts on the blockchain can further obtain the approval signature list constructed by these approval signature information (for example, list R = {Sin (A), Sin (B), Sin (C})) when collecting the approval signature information (for example, signature information such as Sin (A), Sin (B), and Sin (C)) obtained by any three of the four approval objects for the signature approval of the same signature content. In this way, after the resource service device submits the signature transaction containing the approval signature list (for example, list R = {Sin (A), Sin (B), Sin (C})) to the consensus node, the consensus node can obtain the approval signature list obtained from the received signature transaction. The obtained approval signature list is passed into the resource management contract to determine through the resource management contract whether the number of signatures of the approval signature information in the approval signature list reaches the signature threshold (i.e., the multi-signature threshold). If reached, the individual approval signature information can be restored from the transaction parameters of the signature transaction, for example, the above-mentioned Sin(A), Sin(B), and Sin(C), and then these restored approval signature information can be multi-signature verified. The multi-signature verification here refers to verifying the multiple signatures of these approval signature information for the same modification business event. For example, whether the approval object corresponding to these approval signature information is the approval registration object after the on-chain address has been registered on the blockchain. If the consensus node determines that it is, the resource management contract here can be called to execute the aforementioned modification business event.

[0060] The registered approval object is essentially a registered approval object that participates in address management for one or more contract addresses in the business space. A modification business event can be a request to add an object as an approval object that participates in address management for one or more contract addresses in the business space. Alternatively, a modification business event can be a request to remove a registered approval object from address management for one or more contract addresses in the business space.

[0061] 5. Business space. A group of approval objects (e.g., a group of approvers) can create multiple contract addresses in the business service platform provided by the resource business service system. The space formed by these contract addresses can be collectively referred to as a business space. In this business space, a contract address can correspond to a resource management contract on the blockchain. In this embodiment of the application, objects used to perform centralized operations (e.g., centralized modification operations) on different contract addresses in the business space can be collectively referred to as management objects, and objects participating in the approval and signing of the same signature content can be collectively referred to as approval objects. One approval object can correspond to an approval group. The approval objects in the same approval group are a group of approvers. This group of approvers can manage different assets through different contract addresses in the business space. It is understandable that multiple contract addresses under the same group of approvers are all owned by this group of approvers, and the different contract addresses owned by this group of approvers are collectively used to constitute the same business space. It should be understood that in this embodiment of the application, any approver (i.e., approval object) in the same group of approvers can participate in address management of different contract addresses in the same business space. Therefore, the embodiment of the present application can collaborate with approvers (i.e., approval objects) in different groups of approvers to participate in the approval signature of different contract addresses in the same business space, so as to realize multiple signatures when approving and signing the same signature content during the address management process.

[0062] Among them, address management may include but is not limited to centrally adding a new approval object (i.e., a business approval object, for example, the business approval object may be approval object Ue) for different contract addresses in the same business space (for example, contract address D1, contract address D2, contract address D3, and contract address D4), and centrally removing or deleting an approval object (for example, an approval registration object) for different contract addresses in the same business space (for example, contract address D1, contract address D2, contract address D3, and contract address D4). The approval registration object here refers to the approval object whose address has been registered on the corresponding blockchain.

[0063] It should be understood that in the embodiment of the present application, any operation on different contract addresses in the business space (for example, the above-mentioned centralized modification operation or asset transfer operation, etc.) requires the approval objects (i.e., approvers) in each approval group associated with the business space to perform multiple signatures on the same signature content containing the same Merkle tree root involved in the embodiment of the present application in accordance with the multi-signature strategy. It should be understood that in the embodiment of the present application, the approval objects (i.e., approvers) in each approval group that can participate in the approval signature in accordance with the multi-signature strategy can constitute a group of multi-signature objects. For example, these approval objects in a group of multi-signature objects are the M approval objects associated with the business space, where M is a positive integer greater than 1.

[0064] In this way, the consensus node on the blockchain can determine, according to the multi-signature strategy, that the number of groups in the approval group of the approval objects participating in the multi-signature reaches the group number threshold, and that the number of these approval objects (i.e., the number of signatures) from different approval groups also reaches the signature threshold. Then, when it is determined that the number of signatures (i.e., the number of groups and the number of signatures) counted during the multi-signature verification of the approval signature information of these approval objects reaches the multi-signature threshold, it can be determined that the approval business status after these approval objects (i.e., the approvers) perform the approval operation (i.e., the approval signature) on the same signature content (e.g., signature content B1) is approved. The signature content B1 here can be the signature content that needs to be signed by the management object performing a centralized modification operation (e.g., operation X1) on different contract addresses in the business space through the management terminal. It should be understood that, further, the consensus node on the blockchain can also write the operation X1 and the multi-signature information for the operation X1 (i.e., the approval signature information of each approval object mentioned above) into the resource management contract corresponding to the corresponding contract address.

[0065] Optionally, the consensus node on the blockchain can also directly count whether the number of approval objects (i.e., the number of signatures) participating in the multi-signature has reached the signature threshold without dividing the approval groups. Then, when the number of approval objects (i.e., the number of signatures) has reached the signature threshold, it can be determined that the number of signatures counted when the multi-signature verification of the approval signature information of these approval objects (i.e., the number of signatures here) has reached the multi-signature threshold. Then, it can be determined that the approval business status after the operations of different contract addresses in the business space (for example, operation X1) approved by these counted approvers is in the approved status.

[0066] For further information, see Figure 1 , Figure 1 This is a schematic diagram of a system architecture provided by an embodiment of this application. This system architecture is applicable to the blockchain-based data processing system involved in this application. Figure 1 As shown, the system architecture may include a consensus network 100a, a consensus network 100b, an approval terminal cluster 300a, and a resource service device 130a.

[0067] It should be understood that in Figure 1 In the consensus network 100a shown, multiple consensus nodes are deployed. The multiple consensus nodes here can specifically include Figure 1 The consensus nodes 10a, 10b, 10c and 10d are shown. It should be noted that the number of consensus nodes deployed in the consensus network 100a is not limited. Figure 1 As shown, for multiple consensus nodes running in the consensus network 100a, the blockchain they jointly maintain is specifically Figure 1 Blockchain 10e is shown.

[0068] By analogy, in Figure 1 In the consensus network 100b shown, multiple consensus nodes are deployed. The multiple consensus nodes here can specifically include Figure 1 The consensus nodes 11a, 11b, 11c and 11d are shown. It should be noted that the number of consensus nodes deployed in the consensus network 100b is not limited here. Figure 1 As shown, for multiple consensus nodes running in the consensus network 100b, the blockchain they jointly maintain is specifically Figure 1 Blockchain 11e is shown.

[0069] like Figure 1 The resource service device 130a shown can interact with the consensus nodes deployed in the consensus network 100a and the consensus nodes deployed in the consensus network 100b. Figure 1 The approval terminal cluster 300a shown provides resource service business, so that each approval terminal in the multiple approval terminals located in the approval terminal cluster 300a can collaboratively participate in the multi-signature of the Merkle tree root of different contract addresses in a certain business space. This means that the embodiment of the present application does not need to perform multiple multi-signatures for each contract address in the business space, but only needs to perform one multi-signature for the Merkle tree root of each contract address selected from the business space, thereby fundamentally improving the efficiency of multi-signature for different contract addresses in the business space through one multi-signature.

[0070] It should be noted that the entire blockchain network associated with the above-mentioned blockchain-based data processing system may include but is not limited to the above-mentioned consensus network 100a and consensus network 100b, and the specific structure of the blockchain network will not be limited here.

[0071] It can be understood that in the embodiment of the present application, the approval terminals deployed in the approval terminal cluster 300a may include: smart phones, tablet computers, laptops, desktop computers, wearable devices (such as smart watches, smart bracelets), smart homes, head-mounted devices, smart cars and other smart terminals.

[0072] In this embodiment of the present application, the resource service device 130a can interact with the consensus nodes in the consensus network 100a and the consensus network 100b for data. For example, the resource service device 130a can be used to receive approval signature information after multiple approval terminals associated with a certain business space have approved and signed the same signature content, and can construct an approval signature list associated with these approval terminals based on the received approval signature information, and then determine the Merkle path from the target contract address (for example, contract address i, i is a positive integer less than N) to the Merkle tree root for any one of the multiple contract addresses (for example, N contract addresses, N is a positive integer greater than 1) in the business space. When it is determined that the operator configured for the resource management contract (for example, target resource management contract) corresponding to the target contract address (for example, contract address i) is the target operator (for example, operator i corresponding to contract address i), the target transaction parameters containing the signature content, the Merkle path and the approval signature list can be signed by the operation private key of the operator i to obtain the target transaction signature information for the target transaction parameters. Furthermore, when constructing a signed transaction (i.e., a target signed transaction) based on the target transaction signature information and target transaction parameters, the resource service device can further submit the signed transaction (i.e., the target signed transaction) to the consensus node running the target resource management contract.

[0073] For ease of understanding, in the embodiment of the present application, any consensus node in the consensus network 100a may be collectively referred to as a first consensus node, and any consensus node in the consensus network 100b may be collectively referred to as a second consensus node. For example, if the resource management contract (i.e., the target resource management contract) corresponding to the above-mentioned contract address i is deployed on the blockchain 10e, then the consensus node running the resource management contract (i.e., the target resource management contract) corresponding to the contract address i may be any consensus node in the consensus network 100a (i.e., the first consensus node). Alternatively, if there is another target contract address (e.g., contract address k, k is a positive integer less than or equal to N, and j is not equal to k) corresponding to the resource management contract (i.e., another target resource management contract) deployed on the blockchain 11e among the N contract addresses, then the consensus node running the target resource management contract may be any consensus node in the consensus network 100a (i.e., the second consensus node).

[0074] It is understandable that the resource management contract deployed on the first consensus node and the resource management contract deployed on the second consensus node can be the same or different, and this will not be repeated on different blockchains (for example, Figure 1 The specific types of resource management contracts deployed on the blockchain 10e and blockchain 11e shown are limited.

[0075] It should be understood that in the embodiment of the present application, the resource service device 130a used to submit a signature transaction (i.e., a target signature transaction) can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0076] For further understanding, please see Figure 2 , Figure 2 This is a schematic diagram of a data interaction scenario provided by an embodiment of the present application. Figure 2 The resource service device 20b shown can be the above Figure 1 The resource service device 130a in the corresponding embodiment. The service system where the resource service device 20b is located is a resource business service system, which includes a resource service device 130a for providing background resource services and a business terminal cluster for providing a visual operation interface, wherein the business terminal cluster here may include but is not limited to a user terminal cluster for performing target business operations (for example, address management operations and resource transfer operations), and an approval terminal cluster for performing approval operations in coordination with the target business operations.

[0077] For ease of understanding, the embodiment of the present application takes the target business operation as an address management operation as an example. The address management operation here can specifically be an operation performed by the management object on the management terminal to centrally modify N contract addresses in the business space (where N is a positive integer greater than 1).

[0078] For example, the management object corresponding to the management terminal can be Figure 2 The user U1 shown here, the management terminal can be specifically Figure 2 The management terminal 20a shown in FIG. Figure 2 As shown, the management terminal 20a displays the service display interface (ie Figure 2 The display interface 200a) shown in FIG. 200b can use “space” as a unit to represent multiple different contract addresses jointly managed by a group of multi-signature objects. A group of multi-signature objects here can specifically refer to an approval object cluster composed of approval objects from different approval groups, for example, Figure 2 The approval objects in the approval object cluster corresponding to the approval terminal cluster Q1 shown can be specifically Figure 2 The user U11, user U21, user U31 and user U41 shown, these approval objects can be used to constitute a set of multi-signature objects for multiple different contract addresses in the common management space S1.

[0079] For example, multiple contract addresses in space S1 (i.e., N contract addresses, for example, N=4) can be specifically Figure 2 The contract addresses D1, D2, D3 and D4 are shown. For example, the multiple contract addresses in space S2 (i.e., N contract addresses, the value of N is not limited here) can be Figure 2 The contract address D5, contract address D6...contract address Dn are shown.

[0080] like Figure 2 As shown, user U1 can use the management terminal 20a to manage N contract addresses (for example, Figure 2 As shown, N=4) for address management. Among them, the control 2a can be a new control for the approver, and the new control can be used to indicate that the user U1 is a certain space (ie, business space, for example, Figure 2 The different contract addresses in the space S1 shown in the figure are collectively added with a new approver (i.e., an approval object to be registered and written to the blockchain). Among them, the control 2b can be an approver removal control, which can be used to indicate that the user U1 is a certain space (i.e., a business space, for example, Figure 2The different contract addresses in the space S1 shown in the figure are collectively removed from a certain approver (i.e., an approval object that has been registered and written to the blockchain). Among them, the control 2c can be an approver update control, which can be used to instruct the user U1 to centrally manage a certain space (i.e., a business space, for example, Figure 2 An approver from a group of approvers with different contract addresses in the space S1 shown (i.e., an approval object registered in approval group 1 written on the blockchain) is updated to another approver.

[0081] For ease of understanding, the embodiment of the present application takes the address management operation as an example of the approver adding operation indicated by the trigger control 2a (i.e., approver adding control). User U1 can modify the four contract addresses (i.e., Figure 2 The management terminal 20a can perform a selection operation on the four contract addresses (for example, the contract address D1, the contract address D2, the contract address D3 and the contract address D4 shown in FIG2 ) so that the management terminal 20a can highlight the four contract addresses on the display interface 200a in response to the selection operation on the four contract addresses (for example, Figure 2 As shown, the four selected contract addresses can be highlighted in the selection areas corresponding to the four contract addresses. Furthermore, user U1 can trigger control 2a (i.e., the approver add control) on the display interface 200a to pop up the business display area corresponding to control 2a (i.e., the approver add control), so that user U1 can enter the approval address of the approver to be added in the business display area.

[0082] Optionally, the business display area can also display the various approval groups used to centrally manage the business space S1, so that user U1 can select an approval group from these approval groups (for example, approval group A1, approval group A2, approval group A3, approval group A4) as the target approval group, and then enter the approval address of the approver to be added under the selected target approval group.

[0083] It should be understood that in an embodiment of the present application, when user U1 selects a target approval group from multiple approval groups, he or she can also trigger a list display button associated with the target approval group to display one or more approval objects that can currently participate in the approval operation in the group list corresponding to the target approval group, and can synchronously display the approval addresses of one or more approval objects in the group list.

[0084] It is understandable that the approval terminal cluster associated with the current space (for example, space S1) can be Figure 2The approval terminal cluster Q1 is shown. The approval terminal cluster Q1 is determined by the approval terminals corresponding to the approval objects in the multiple approval groups associated with the space S1. The approval addresses of each approval object displayed in the approval terminal cluster Q1 are all blockchain addresses after the addresses are registered on the corresponding blockchain.

[0085] For ease of understanding, here we take the number of approval objects under each approval group as one as an example, then the approval objects under approval group A1 may include Figure 2 As shown, the user U11 can approve the following items under the approval group A2: Figure 2 As shown, the user U21 can approve the following items under the approval group A3: Figure 2 As shown, the user U31 can approve the following items under the approval group A4: Figure 2 User U41 is shown.

[0086] For ease of understanding, here we take the N contract addresses selected by user U1 in space S1 (i.e. Figure 2 The contract addresses D1, D2, D3 and D4 shown in the figure are from the same blockchain (the blockchain here can be Figure 2 The contract addresses of the different resource management contracts deployed on the blockchain 21e) shown.

[0087] like Figure 2 As shown, after user U1 completes the selection operation of the N contract addresses (for example, V contract addresses, V is a positive integer greater than or equal to N) recorded in space S1, he can further complete the entry operation of the approval address of the newly added approval object in the above business display area to generate a modification business event (for example, Event1) triggered for these four contract addresses. In this way, when user U1 confirms the triggering of the modification confirmation control, he can execute Figure 2 In step S11, a management request for the space S1 where the four contract addresses are located is sent to the resource service device. In this way, when the resource service device 20b obtains the space management request, it can execute step S12 to select the N contract addresses (i.e. Figure 2 The contract address D1, contract address D2, contract address D3 and contract address D4 shown in the figure are used to calculate the Merkle tree root (e.g., Root1) associated with these four contract addresses.

[0088] Further, such as Figure 2As shown, after calculating the Merkle tree root (e.g., Root1), the resource service device can construct the signature content to be signed (e.g., signature content B1) based on the calculated Merkle tree root (e.g., Root1) and the modification business event for the four contract addresses carried in the current space management request (e.g., Event1), and can generate a space management request for distribution to each approval terminal based on the signature content to be signed (e.g., signature content B1).

[0089] Further, such as Figure 2 The resource service device 20b shown in FIG. 1 can distribute the space management request to the resource service device 20b when executing step S12. Figure 2 The various approval terminals in the approval terminal cluster Q1 shown are M approval terminals associated with the space S1 (i.e., the business space). In other words, M here can be used to represent the number of all approval terminals in the approval terminal cluster Q1. For ease of understanding, M=4 is used as an example. Figure 2 As shown, among the four approval terminals, the approval terminal 120a can be the approval object in the above approval group A1 (ie Figure 2 The approval terminal 120b is used to execute the approval operation (ie, approval signature) in the multi-signature. Similarly, the approval terminal 120b can be the approval object (ie, Figure 2 The approval terminal 120c is used to perform the approval operation (i.e., approval signature) in the multi-signature. Similarly, the approval terminal 120c can be the approval object (i.e., Figure 2 The approval terminal 120d can be the approval object (ie, the approval signature) in the approval group A4. Figure 2 The user U41 shown is an approval terminal corresponding to the multi-signature for performing the approval operation (ie, approval signature).

[0090] like Figure 2 As shown, when the approval terminal under each approval group obtains the space management request, it can execute step S13 to parse the signature content to be signed (for example, signature content B1) from the space management request. In other words, when executing step S13, each approval terminal in the approval terminal cluster Q1 can use the private key corresponding to the approval address of each approval object to approve the signature content B1 carried in the space management request to obtain the approval signature information for the signature content B1.

[0091] For example, during the multi-signature process, user U11 can obtain the private key corresponding to the approval address of user U11 (for example, approval address D11) through the approval terminal 120a, and then when the signature content B1 is approved and signed by the obtained private key of user U1, the approval signature information of user U1 (for example, Sin(D11)) can be obtained; user U21 can obtain the private key corresponding to the approval address of user U21 (for example, approval address D21) through the approval terminal 120b, and then when the same signature content (i.e., signature content B1) is approved and signed by the obtained private key of user U21, the approval signature information of user U21 (for example, Sin(D21)) can be obtained. Similarly, user U31 can obtain the private key corresponding to user U31's approval address (e.g., approval address D31) through approval terminal 120c. Furthermore, when the same signature content (i.e., signature content B1) is approved and signed using the obtained private key of user U31, user U31's approval signature information (e.g., Sin(D31)) can be obtained. Similarly, user U41 can obtain the private key corresponding to user U41's approval address (e.g., approval address D41) through approval terminal 120d. Furthermore, when the same signature content (i.e., signature content B1) is approved and signed using the obtained private key of user U41, user U41's approval signature information (e.g., Sin(D41)) can be obtained.

[0092] It should be understood that in the embodiment of the present application, after completing the approval signature for the same signature content, the approval objects in each approval group can execute step S14 to return the obtained approval signature information for the signature content B1 to the resource service device 20b.

[0093] In this way, the resource service device 20b can further execute step S15 to construct an approval signature list associated with the four approval terminals based on the obtained approval signature information, for example, the above-mentioned Sin(D11), Sin(D21), Sin(D31), and Sin(D41) (for example, R11 = {Sin(D11), Sin(D21), Sin(D31), Sin(D41)}). Furthermore, the resource service device 20b can use the contract address D1 as the target contract address among the above-mentioned four contract addresses (i.e., contract address D1, contract address D2, contract address D3, and contract address D4), and then determine the target Merkle path (e.g., Path1) from the target contract address (i.e., contract address D1) to the Merkle tree root (e.g., Root1) in the Merkle tree where the Merkle tree root (e.g., Root1) in the signature content B1 is located.

[0094] Furthermore, the resource service device 20b can assemble the target transaction parameters associated with the target contract address based on the constructed approval signature list (for example, R11 = {Sin(D11), Sin(D21), Sin(D31), Sin(D41)}), the target Merkle path (for example, Path1), and the signature content B1, and then obtain the target operator (i.e., the target operation object, for example, Figure 2 The operator C1 shown in the figure uses the operation private key to sign the target transaction parameters to obtain transaction signature information, and then a signed transaction (for example, Figure 2 The signed transaction TX1 shown in FIG. 1 is thus submitted to the consensus node running the target resource management contract (e.g., Figure 2 The target consensus node shown in FIG1 is a target consensus node, so that the target consensus node can further execute step S17. In other words, at this time, the target consensus node can perform transaction verification on the signed transaction TX1, and then determine the authenticity and reliability of the parameter source of the transaction parameters in the signed transaction TX1 signed by the above-mentioned target operator (i.e., the target operation object) through transaction verification. Furthermore, when the target consensus node executes step S17, it can also obtain transaction parameters with authenticity and reliability of parameter sources when the transaction verification is successful. It can then perform multi-signature verification on the Merkle tree root (for example, the above-mentioned Root1) in the transaction parameters while performing root verification on the approval signature list in the transaction parameters. It can then determine that the transaction verification is successful when the root verification is successful and the multi-signature verification is successful, so that when the above-mentioned signature content B1 is restored, the modification business event in the signature content B1 can be executed.

[0095] Among them, such as Figure 2 As shown, the consensus network where the target consensus node is located is consensus network 200b. It is understandable that if the consensus network 200b is the above Figure 1 The consensus network 100a shown in FIG, the target consensus node here (i.e. Figure 2 The consensus node 21a) shown in the figure can be the first consensus node mentioned above. In this case, the contract address of the resource management contract running on the first consensus node can be Figure 2 The contract address D1 is shown. This means that the blockchain maintained by these consensus nodes in the consensus network 200b (i.e., the first blockchain, for example, Figure 2 The blockchain 21e shown can be the above Figure 1 The four different contract addresses selected by the user U1 in the above-mentioned business space (i.e., space S1) can be deployed on the blockchain 10e) shown.

[0096] Optionally, if the consensus network 200b is the above Figure 1 The target consensus node here can be the second consensus node mentioned above. At this time, the contract address of the resource management contract running on the second consensus node can be Figure 2 The contract address D1 is shown. This means that the blockchain maintained by these consensus nodes in the consensus network 200b (i.e., the second blockchain, for example, Figure 2 The blockchain 21e shown can be the above Figure 1 The four different contract addresses selected by the user U1 in the above-mentioned business space (i.e., space S1) can be deployed on the blockchain 11e) shown.

[0097] Among them, it is understandable that Figure 2 The management terminal 20a shown can be used to display different contract addresses in one or more spaces centrally managed by the management object. For ease of understanding, the embodiment of the present application can refer to a space (for example, the above-mentioned space S1) selected by the management object on the management terminal 20a as a business space. Figure 2 As shown, the space centrally managed by the management object may include but is not limited to Figure 2 It should be understood that in the embodiment of the present application, one space may correspond to one approval terminal cluster. For example, the approval terminal cluster corresponding to space S1 may be Figure 2 The approval terminal cluster Q1 shown in the figure, similarly, the approval terminal cluster corresponding to space S2 can be the approval terminal cluster Q2 (not shown in the figure). Figure 2 shown above).

[0098] For example, the management terminal here (for example, Figure 2 The management terminal 20a) shown can be used to perform Figure 2 The centralized modification operation of different contract addresses in the space S1 shown (for example, adding a new approval operation of a certain approver to the different contract addresses selected from the space S1). Similarly, the management terminal here (for example, Figure 2 The management terminal 20a) shown can also be used to perform Figure 2 The centralized modification operation of different contract addresses in the space S2 shown (for example, the approval addition operation of adding a certain approver to different contract addresses selected from the space S2)

[0099] Among them, it is understandable that Figure 2The management terminal 20a shown may be a first management terminal for centrally managing different contract addresses in multiple spaces. In other words, the first management terminal here may be another terminal device independent of each approval terminal in each approval terminal cluster, that is, the first management terminal here (for example, Figure 2 The management terminal 20a) shown does not belong to the approval terminal in the approval terminal cluster corresponding to each space. Optionally, in one or more implementations, Figure 2 The management terminal 20a shown can also be a second management terminal for centrally managing different contract addresses in the corresponding space. In this case, the second management terminal here can be any approval terminal selected from the approval terminal cluster corresponding to the corresponding space.

[0100] Specifically, it is understood that the management terminal 20a here is integrated with a resource management client. When a user (ie, the above-mentioned management object, for example, Figure 2 When the user U1) shown in FIG. 1 successfully accesses the resource management client through the management terminal 20a, the resource management client can display the resource management client. Figure 2 The display interface 200a shown can further display different contract addresses in one or more spaces centrally managed by the management object on the display interface 200a.

[0101] It should be understood that in the embodiment of the present application, since the management object (e.g. Figure 2 The user U1 shown in the figure is in the business space (for example, Figure 2 The number of contract addresses selected in the space S1 shown (i.e., N) is 4. Considering that each contract address corresponds to a different resource management contract on a certain blockchain, when these 4 contract addresses are different contract addresses on the same blockchain, the resource service device 20b can store the private key information of 4 operators (i.e., operation objects) corresponding to the 4 resource management contracts. For ease of understanding, in this embodiment of the application, the private key information of each operator (i.e., operation object) stored by each resource service device 20b can be collectively referred to as an operation private key. Then, when each operator authorizes a transaction signature through an operation terminal, the resource service device 20b can use the operation private keys of different operators to respectively sign the transaction parameters associated with different contract addresses currently constructed.

[0102] Among them, it can be understood that in the embodiment of the present application, the resource service device will determine the Merkle path of different contract addresses in the process of constructing different transaction parameters associated with different contract addresses. For example, the transaction parameters associated with the contract address D1 may include the signature content B1 carrying the Merkle tree root (for example, the above-mentioned Root1), the approval signature list carrying the approval signature information of each approval object (for example, the above-mentioned R11) and the determined Merkle path of the contract address D1 (for example, the above-mentioned Path1, where Path1 refers to the path from the contract address D1 to the Merkle tree root). For another example, another transaction parameter associated with the contract address D2 may include the signature content B1 carrying the Merkle tree root, the approval signature list carrying the approval signature information of each approval object (for example, the above-mentioned R11) and the determined Merkle path of the contract address D2 (for example, Path2, where Path2 refers to the path from the contract address D2 to the same Merkle tree root). Similarly, another transaction parameter associated with contract address D3 may include the signature content B1 carrying the Merkle tree root, the approval signature list carrying the approval signature information of each approval object (for example, the above R11), and the determined Merkle path of contract address D3 (for example, Path3, where Path3 refers to the path from contract address D3 to the same Merkle tree root). Similarly, another transaction parameter associated with contract address D4 may include the signature content B1 carrying the Merkle tree root, the approval signature list carrying the approval signature information of each approval object (for example, the above R11), and the determined Merkle path of contract address D4 (for example, Path4, where Path4 refers to the path from contract address D4 to the same Merkle tree root).

[0103] Furthermore, it is understood that the resource service device 20b can synchronously obtain four signed transactions after signing the transaction parameters carrying different Merkle paths using the operator's private operation key configured for four different resource management contracts. Furthermore, it can submit four signed transactions carrying different Merkle paths to the target consensus node running these four resource management contracts. For example, these four signed transactions carrying different Merkle paths can be transaction TX1, transaction TX2, transaction TX3, and transaction TX4. The specific method for obtaining transaction TX2, transaction TX3, and transaction TX4 can be found in the description of the specific process for obtaining transaction TX1 in the embodiment of this application, and will not be further elaborated here.

[0104] Optionally, if the management object (e.g. Figure 2The four resource management contracts corresponding to the four contract addresses selected by the user U1 in a certain space (for example, space S1) through the management terminal 20a are not resource management contracts deployed on the same blockchain, so that the efficiency of address management of different contract addresses in the same business space can be achieved across chains.

[0105] For example, if the resource management contract corresponding to the contract address D1 and the resource management contract corresponding to the contract address D2 are the resource management contracts on the first blockchain, then Figure 2 The resource service device 20b shown can submit the constructed transactions TX1 and TX2 to the first consensus node for maintaining the first blockchain (for example, the above Figure 1 Alternatively, if the resource management contract corresponding to the contract address D3 and the resource management contract corresponding to the contract address D3 are the resource management contracts on the second blockchain, then Figure 2 The resource service device 20b shown can submit the constructed transactions TX3 and TX4 to the second consensus node for maintaining the second blockchain (for example, the above Figure 1 Consensus nodes in the consensus network 100b shown).

[0106] Among them, it needs to be explained that when acquiring and using object access information, approval signature information, operation private keys, virtual assets and other data, the embodiment of the present application can display a prompt interface or pop-up window. The prompt interface or pop-up window is used to prompt the user that object access information, approval signature information, operation private keys and other data are currently being collected. Only after the user issues a confirmation operation on the prompt interface or pop-up window, the relevant steps of data acquisition are started, otherwise it ends.

[0107] All data collected or obtained by the embodiments of this application (such as private operation keys, etc.) are collected or obtained with the consent and authorization of the corresponding objects (such as the aforementioned operation objects). In other words, when the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0108] It should be understood that the specific process of constructing an approval signature list (e.g., a first approval signature list) and constructing a signed transaction (e.g., a first signed transaction) through a resource service device in the embodiment of the present application can be found in Figure 3-Figure 14 Description of the corresponding embodiment.

[0109] For further information, see Figure 3 , Figure 3This is a data processing method based on blockchain provided by an embodiment of the present application. The method is executed by a resource service device in a resource business service system. The resource service device here can be the above-mentioned Figure 2 The resource service device 20b in the corresponding embodiment. The business space of the resource business service system includes N contract addresses, N is a positive integer greater than 1, the N contract addresses include contract address i, the operation object corresponding to contract address i is operation object i, the resource management contract corresponding to contract address i is the resource management contract i on the blockchain, i is a positive integer less than or equal to N. Figure 3 As shown, the method may at least include steps S101 to S104.

[0110] Step S101, obtaining space management requests associated with N contract addresses;

[0111] Among them, the first signature content carried in the space management request here can specifically include the Merkle tree root associated with N contract addresses and the modification business event triggered for the N contract addresses.

[0112] It can be understood that the resource service device involved in the embodiment of the present application can receive a management request sent by a management terminal, and then can generate a space management request associated with N contract addresses for distribution to each approval terminal based on the modification business event corresponding to the centralized modification operation performed on N contract addresses carried in the management request. It can be understood that the N contract addresses here can be part or all of the contract addresses selected by the management object corresponding to the management terminal from the V contract addresses specifically contained in a certain space, that is, V here can be a positive integer greater than or equal to N.

[0113] In other words, in an embodiment of the present application, the management object can display one or more spaces that it can centrally manage on the business display interface of the management terminal, and then collectively refer to the spaces that it currently needs to manage as business spaces in the displayed one or more spaces, so that N contract addresses can be selected from the multiple contract addresses (for example, V contract addresses) contained in the business space. This means that the management object involved in the embodiment of the present application can perform centralized modification operations on some or all contract addresses selected from the business space. The centralized modification operation here can specifically be the above-mentioned address management operation. For example, the address management operation may include but is not limited to the approver addition operation indicated by the above-mentioned approver update control, the approver removal operation indicated by the approver removal control, and the approver update operation indicated by the approver update control.

[0114] Among them, the number of approval terminals in the approval terminal cluster associated with the space currently selected by the management object (i.e., the business space) can be M. At this time, the M management terminals associated with the business space can be the first management terminal, and the management object corresponding to the first management terminal can specifically be the first management object.

[0115] At this time, when executing step S101, the resource service device can be used to flexibly configure the corresponding space operation sequence number for this centralized modification operation when receiving the management request (i.e., the first management request) associated with the N contract addresses sent by the first management terminal, and can further use the calculated Merkle tree root, the space operation sequence number, the modification timestamp corresponding to the modification business event, and the modification business event to construct the signature content (i.e., the first signature content) to be approved and signed by the approval object when the Merkle tree root of the N contract addresses is calculated.

[0116] Specifically, the resource service terminal can receive a system access request submitted by the first management terminal, and can authenticate the management object corresponding to the first management terminal based on the object access information carried in the system access request to obtain an authentication result; further, if the authentication result indicates that the management object has access rights to access the resource business service system, the resource service terminal can return a business service page provided by the resource business service system to the first management terminal; further, the resource service terminal can receive a first management request sent by the first management terminal; the first management request here is generated by the first management terminal in response to a centralized modification operation performed on N contract addresses on the business service page, based on a modification business event corresponding to the centralized modification operation; further, the resource service terminal can configure a space operation sequence number corresponding to the centralized modification operation based on the first management request; in this way, the resource service terminal can obtain the Merkle tree root associated with the N contract addresses, and can use the Merkle tree root, the space operation sequence number, the modification timestamp corresponding to the modification business event, and the modification business event as the first signature content to be signed, and then can determine the space management request associated with the N contract addresses based on the first signature content.

[0117] For further understanding, please visit Figure 4 , Figure 4 This is a schematic diagram of a scenario in which a resource business service system provides a visual business service page to a management terminal. The management terminal here can be the first management terminal mentioned above, which can be Figure 4 The management terminal 40a corresponding to the user U2 (ie, another management object) shown in the figure can display a business service page on the management terminal 40a. Figure 4It is understood that before the management terminal 40a loads and displays the display interface 400a (i.e., the business service page), the user U2 (i.e., the management object) can execute step S21 through the management terminal 40a to submit the request to the resource service device 40b. Figure 4 This means that when the resource service device 40b receives the system access request submitted by the management terminal 40a (i.e., the first management terminal), it can execute the object access information carried in the system access request (for example, the first access account information entered by the user U2 through the management terminal 40a for requesting access to the resource service system). Figure 4 Step S22 is shown to authenticate the user U2. In other words, in this embodiment of the present application, when authenticating the user U2, the resource service device can search the access database corresponding to the resource business service system for registration access information (e.g., first registration account information) that matches the object access information (e.g., first access account information). If found, the resource service device 40b can use the authentication success result of the registration access information (e.g., first registration account information) that matches the object access information (e.g., first access account information) found as the authentication result. It should be understood that the successful authentication result here can be used to indicate that the user U2 (i.e., the management object, which can specifically refer to the first management object) has the access authority to access the resource business service system, and then based on the access authority, the contract address in one or more spaces centrally managed by the user U2 can be obtained from the business database corresponding to the resource business service system, and the obtained contract address in one or more spaces centrally managed by the user U2 can be used as page data of the business service page, and then based on the page data and the rendering template matching the first management terminal, a business display interface (for example, Figure 4 The display interface 400a shown in FIG. Figure 4 In step S23 shown, the business service page (eg, Figure 4 Display interface 400a shown).

[0118] It is understandable that, upon receiving the business service page (specifically, the page data of the business service page) returned by the resource service device 40b, the management terminal 40a can Figure 4The display interface 400a shown in the figure outputs these page data quickly according to the rendering template that matches the first management terminal, and can quickly output and display the contract addresses in one or more spaces centrally managed by the user U2 on the display interface 400a. Figure 2 As shown, multiple contract addresses in space S1 (for example, contract address D1, contract address D2, contract address D3 and contract address D4) and multiple contract addresses in space S3 (for example, contract address D5, contract address D6, contract address D7, contract address D8 and contract address D9) can be displayed on the display interface 400a.

[0119] Further, such as Figure 4 As shown, user U2 can select a space (for example, Figure 4 The space S3 shown in the figure is used as the business space, and then multiple contract addresses contained in the business space (that is, the above-mentioned V contract addresses, for ease of understanding, the V contract addresses here take 5 contract addresses as an example, these 5 contract addresses can specifically include Figure 4 Select the contract address that needs to be modified from the contract address D5, contract address D6, contract address D7, contract address D8, and contract address D9 shown in the figure. For example, Figure 4 As shown, user U2 can select N contract addresses from the V contract addresses contained in the space S3. The N contract addresses here can specifically include the contract address D5, contract address D6, contract address D7 and contract address D9 selected by the user U2 in the space S3 currently serving as the business space.

[0120] Furthermore, it is understood that user U2 can trigger a control in the display interface 400a for performing a centralized modification operation on the currently selected N contract addresses. For ease of understanding, the control for performing the modification operation is used as Figure 4Taking the "Add Approver" control shown as an example, this means that at this time, after triggering the "Add Approver" control, user U2 can execute the approver addition operation indicated by the approver addition control (for example, the approval address of the approver to be added, such as approval address D12), and when executing the modification confirmation operation indicated by the modification confirmation control for the approver addition operation, the user U2 can further submit the modification business event corresponding to the current modification confirmation operation (i.e., the approver addition event) to the resource service device 40b in the form of a request (e.g., a first management request), so that the resource service device can configure the space operation sequence number corresponding to this centralized modification operation (e.g., the approval addition operation indicated by the approver addition control) based on the first management request when receiving the first management request sent by the management terminal 40a (i.e., the first management terminal). That is, the resource service device 40b can flexibly configure the variable value of the operation sequence number variable of this centralized modification operation based on the first management request. For example, the operation sequence number variable can be recorded as a Nonce variable, and the variable value of the operation sequence number variable can be an integer value of the Nonce variable.

[0121] It should be understood that in the embodiment of the present application, the resource management contract corresponding to each contract address will independently maintain a contract operation serial number. The contract operation serial number here can be explained by the Nonce variable, that is, the embodiment of the present application can use the Nonce variable here to represent the serial number of the operation performed on the resource management contract corresponding to a certain contract address.

[0122] The operations here may include, but are not limited to: address management operations on the contract address corresponding to the resource management contract and resource transfer operations on the virtual resources in the resource management contract. It should be understood that in the embodiments of the present application, any type of operation performed on the resource management contract will affect the dynamic increment of the variable value of the Nonce variable (i.e., the operation sequence number) maintained by the current resource management contract.

[0123] In other words, in the process of address management of N contract addresses in the business space, the embodiment of the present application does not need to strictly increment the Nonce variables currently maintained by the resource management contract corresponding to each contract address (that is, there is no need to perform +1 processing on the Nonce values of the Nonce variables maintained by each resource management contract), but instead proposes a new method for determining the space operation sequence number. The new space operation sequence number determination method aims to propose a new Nonce management mode (that is, operation sequence number management mode). For example, the embodiment of the present application can obtain the contract operation sequence numbers currently maintained by the N resource management contracts corresponding to the N contract addresses from the selected N contract addresses, and then can filter out the maximum contract operation sequence number from the obtained contract operation sequence numbers represented by the Nonce variables, so that the operation sequence number of the selected maximum contract can be incremented, so that the maximum contract operation sequence number after the increment processing can be used as the space operation sequence number corresponding to this centralized modification operation.

[0124] For further understanding, please visit Figure 5 , Figure 5 This is a schematic diagram of a scenario for determining a spatial operation sequence number provided by an embodiment of the present application, such as Figure 5 The contract address selected in the business space shown above can be Figure 4 In the corresponding embodiment, N (ie, N=4) contract addresses are selected by user U2 (ie, the first management object mentioned above) in space S3.

[0125] Among them, such as Figure 5 As shown, the resource management contract corresponding to the contract address D5 can be the resource management contract Con5, and the contract operation sequence number currently maintained by the resource management contract Con5 can be Figure 5 The Nonce5 shown; the resource management contract corresponding to the contract address D6 can be the resource management contract Con6, and the contract operation sequence number currently maintained by the resource management contract Con6 can be Figure 5 Nonce6 shown; the resource management contract corresponding to the contract address D7 can be the resource management contract Con7, and the contract operation sequence number currently maintained by the resource management contract Con7 can be Figure 5 Nonce7 shown; the resource management contract corresponding to the contract address D9 can be the resource management contract Con9, and the contract operation sequence number currently maintained by the resource management contract Con9 can be Figure 5 Nonce9 shown.

[0126] like Figure 5 As shown, the resource service device can select the largest contract operation sequence number from the contract operation sequence numbers of each resource management contract.

[0127] It can be understood that the method for determining the maximum contract operation sequence number can be represented by a maximum function (i.e., a Max() function, for example, a Max(Nonce1, Nonce2, Nonce3…NonceN) function), wherein the N Nonce variables in the maximum function can be recorded as Nonce1, Nonce2, Nonce3…NonceN, respectively. These N Nonce variables can be used to represent the contract operation sequence number of the resource management contract corresponding to each of the N contract addresses currently selected in the business space.

[0128] like Figure 5 As shown, since the contract operation sequence number of the resource management contract corresponding to contract address D5 is Nonce5, the contract operation sequence number of the resource management contract corresponding to contract address D6 is Nonce6, the contract operation sequence number of the resource management contract corresponding to contract address D7 is Nonce7, and the contract operation sequence number of the resource management contract corresponding to contract address D9 is Nonce9. At this time, the space operation sequence number = Max(Nonce5, Nonce6, Nonce7, Nonce9)+1.

[0129] For ease of understanding, here we take Nonce5>Nonce6>Nonce7>Nonce9 as an example. At this time, the maximum contract operation number determined by the resource service device through the Max() function can be Figure 5 The contract operation sequence number currently maintained by the resource management contract Con5 shown (for example, Figure 5 As shown in Nonce5). Further, Figure 5 As shown, the resource management device can select the maximum contract operation sequence number (for example, Figure 5 Nonce5) is incremented to obtain the maximum contract operation sequence number after the incrementing process (for example, Figure 5 Nonce5'); further, the resource service device may increment the maximum contract operation sequence number (eg, Figure 5 Nonce5') is determined to be the latest spatial operation sequence determined for the centralized modification operation on N contract addresses.

[0130] Optionally, in the embodiment of the present application, the management object (for example, the above Figure 4 If the user U2 shown in the figure needs to use other business spaces (for example, Figure 4As shown in the space S1), some contract addresses (for example, contract address D1 and contract address D2) in the space S1) are uniformly added with approvers. At this time, for the control operation sequence number corresponding to the centralized modification operation of adding approvers to contract address D1 and contract address D2, the above-mentioned operation sequence number management mode can still be used to filter and determine the maximum Nonce value from the Nonce values maintained by the two resource management contracts corresponding to the two currently selected contract addresses, and then the maximum Nonce value determined by the filter can be added by 1.

[0131] Optionally, by analogy, if the management object (for example, the above Figure 4 The user U2 shown in the figure needs to use other business spaces (for example, Figure 4 If all contract addresses in the space S1 shown (for example, contract address D1, contract address D2, contract address D3 and contract address D4) are uniformly added with an approver, the resource service device can obtain the Nonce values maintained by the four resource management contracts corresponding to these four contract addresses according to the above-mentioned operation sequence management mode, and then select the largest Nonce value from the four obtained Nonce values for +1 processing.

[0132] It should be understood that when the embodiment of the present application constructs the signature content (i.e., the first signature content) for approval and signature by each approver (i.e., the approval object), the reason why the Nonce value for this centralized modification operation (i.e., the above-mentioned space operation sequence number) is introduced into the first signature content is to prevent the same signature content from being replayed for approval and signature, that is, each approval object participating in the approval and signature of the first signature content only needs to perform one approval and signature on the currently obtained signature content. In this way, even if the approval terminals or resource service devices participating in the approval and signature repeatedly receive the above-mentioned space management request sent by the resource service device due to network abnormalities or other reasons, once the signature content carried in the space management request is approved and signed once, the same signature content will not be repeatedly approved and signed, thereby avoiding the waste of approval signature resources.

[0133] At the same time, resource service equipment (for example, the above Figure 4 The resource service device 40b shown in FIG4 can also be based on the N contract addresses (for example, Figure 4The contract address D5, contract address D6, contract address D7 and contract address D9 shown in the figure are obtained to obtain the chain identifier of the resource management contract corresponding to each contract address. Then, it can be determined whether the chain identifiers of the resource management contracts corresponding to these obtained contract addresses are the same chain identifier. Different Merkle tree root calculation strategies can be adaptively adopted according to the judgment results to quickly calculate the Merkle tree roots associated with these N contract addresses.

[0134] It is understood that, in the embodiment of the present application, when determining that the N resource management contracts corresponding to the selected N contract addresses belong to resource management contracts on the same blockchain, the first Merkle root calculation strategy in the Merkle root calculation strategy can be used to determine the chain identifier of the blockchain on which the N resource management contracts are deployed. In this case, the chain identifier of the blockchain determined according to the first Merkle root calculation strategy can specifically be the chain identifier of the first blockchain or the chain identifier of the second blockchain.

[0135] Among them, to facilitate distinction, the embodiment of the present application may collectively refer to the chain identifier of the first blockchain as the first chain identifier, and may collectively refer to the chain identifier of the second blockchain as the second chain identifier.

[0136] For ease of understanding, here we assume that there are N resource management contracts deployed (for example, when N=4, these 4 resource management contracts can be specifically the above Figure 4 Taking the blockchain of the contract address D5, contract address D6, contract address D7 and contract address D8 shown as the first blockchain as an example, at this time, the chain identifier of the first blockchain is the first chain identifier.

[0137] It should be understood that the specific process of the resource service device determining the Merkle tree root (for example, the first Merkle tree root) according to the first Merkle tree root calculation strategy can be described as: the resource service device can concatenate the first chain identifier and each of the N contract addresses to obtain the address splicing information of each contract address; wherein, the address splicing information of a contract address is obtained by splicing the first chain identifier and a contract address; further, the resource service device can perform a hash transformation on the address splicing information of each contract address to obtain an address hash value corresponding to the address splicing information of each contract address; wherein, the address splicing information of a contract address corresponds to an address hash value; further, the resource service device can use the address hash value corresponding to the address splicing information of each contract address as the leaf node of the first Merkle tree, so that the first Merkle tree can be constructed based on the leaf node of the first Merkle tree, and the root node of the first Merkle tree can be used as the first Merkle tree root associated with the N contract addresses.

[0138] For further understanding, please visit Figure 6 , Figure 6 This is a schematic diagram of a scenario for determining the root of the Merkle tree provided by the embodiment of the present application. For ease of understanding, the embodiment of the present application uses N contract addresses selected from the business space as the above Figure 4 Take the 4 contract addresses shown as an example. These 4 contract addresses can be Figure 6 The contract address D5, contract address D6, contract address D7 and contract address D9 are shown.

[0139] like Figure 6 As shown, the four contract addresses here correspond to four resource management contracts. These four resource management contracts can be deployed on the blockchain (for example, the chain identifier is Figure 6 It should be understood that in the embodiment of the present application, a resource management contract deployed on the first blockchain can correspond to a contract address. In the embodiment of the present application, the Merkle root (for example, the first Merkle root) calculated by the resource service device using the above-mentioned first Merkle root calculation strategy can be Figure 6 The hash value on node 63a shown (e.g., Figure 6 H(5679) shown).

[0140] like Figure 6 As shown, in the embodiment of the present application, the resource service device can determine that the chain identifiers of the four resource management contracts corresponding to the four contract addresses are chain L1 based on the four contract addresses (i.e., contract address D5, contract address D6, contract address D7, and contract address D9), and can concatenate the chain identifier L1 with each of the four contract addresses to obtain Figure 6 The address concatenation information of each contract address shown. For example, the address concatenation information of contract address D5 can be Figure 6 The address concatenation information of the contract address D6 in P15 shown can be Figure 6 The address concatenation information of the contract address D7 in P16 shown can be Figure 6 P17 shown in the figure, and so on, the address splicing information of the contract address D9 can be Figure 6 P19 shown.

[0141] It should be understood that in the embodiment of the present application, the Merkle tree (i.e., the first Merkle tree, for example, Figure 6When the Merkle tree 600a shown in the figure is constructed, the hash value of the address splicing information of each contract address in the four contract addresses is used as the node of the Merkle tree 600a to ensure that the Merkle path (i.e., one path) provided when the corresponding resource management contract (i.e., the target resource management contract) is subsequently called on the target consensus node (e.g., the first consensus node) for contract verification does not directly contain the contract address of other resource management contracts.

[0142] for example, Figure 6 The leaf nodes of the Merkle tree 600a (i.e., the first Merkle tree) shown specifically include Figure 6 Node 61a, node 61b, node 61c and node 61d are shown. Among them, the hash value on node 61a (i.e. Figure 6 H(P15)) is the address concatenation information of the contract address D5 (i.e. Figure 6 The address hash value obtained after hash calculation of P15 shown in FIG61a; the hash value on node 61b (ie Figure 6 H(P16)) is the address concatenation information of the contract address D6 (i.e. Figure 6 The address hash value obtained after hash calculation of P16 shown in FIG. 6; the hash value on node 61c (ie Figure 6 H(P17)) is the address concatenation information of the contract address D7 (i.e. Figure 6 The address hash value obtained after hash calculation of P17 shown in FIG61; the hash value on node 61d (ie Figure 6 H(P19)) is the address concatenation information of the contract address D9 (i.e. Figure 6 The address hash value obtained after hash calculation (P19) shown in FIG.

[0143] It is understandable that in the embodiment of the present application, in the process of constructing the first Merkle tree (for example, Merkle tree 600a) based on the address hash value corresponding to the address splicing information of each contract address, the hash value on node 61a and the hash value on node 61b can be hashed and spliced, and then the hash splicing value obtained by the hash splicing can be hashed again to obtain Figure 6 The hash value of node 62a shown in FIG. 5 (i.e., H(56)); Similarly, the embodiment of the present application can perform hash concatenation on the hash value of node 61c and the hash value of node 61d, and then perform hash calculation again on another hash concatenation value obtained by hash concatenation to obtain Figure 6The hash value of node 62b shown in FIG. 7 (i.e., H(79)) is obtained. Similarly, in the embodiment of the present application, the hash value of node 62a and the hash value of node 62b can be hashed together, and then the hashed value obtained by the hashing can be hashed again to obtain Figure 6 The hash value on the node 63a shown (ie, H(5679)), and the root node of the resulting Merkle tree 600a (eg, Figure 6 The hash value (i.e., H(5679)) at node 63a) shown is used as the first Merkle tree root associated with these four contract addresses.

[0144] Optionally, when determining that the N resource management contracts corresponding to the N contract addresses originate from different blockchains, the embodiment of the present application may also determine the Merkle root (for example, the second Merkle root) according to the second Merkle root calculation strategy in the Merkle root calculation strategy.

[0145] Among them, the N contract addresses include N1 first contract addresses and N2 second contract addresses; N=N1+N2, N1 and N2 are both positive integers, the blockchain includes a first blockchain with N1 resource management contracts corresponding to the N1 first contract addresses deployed and a second blockchain with N2 resource management contracts corresponding to the N2 second contract addresses deployed, the chain identifier of the first blockchain is the first chain identifier, the chain identifier of the second blockchain is the second chain identifier, and the Merkle tree root includes the second Merkle tree root associated with the N1 first contract addresses and the N2 second contract addresses; the specific process of the resource service device determining the Merkle tree root according to the second Merkle tree root calculation strategy can be described as: the resource service device can use each of the N1 first contract addresses as the first chain contract address, and can concatenate the first chain identifier and the first chain contract address to obtain the first address of the first chain contract address. further, the resource service device may use each of the N2 second contract addresses as the second chain contract address, and may concatenate the second chain identifier and the second chain contract address to obtain the second address splicing information of the second chain contract address; further, the resource service device may perform a hash transformation on the first address splicing information to obtain a first address hash value corresponding to the first address splicing information, and may perform a hash transformation on the second address splicing information to obtain a second address hash value corresponding to the second address splicing information; further, the resource service device may use the first address hash value and the second address hash value as leaf nodes of a second Merkel tree, respectively, and may construct a second Merkel tree based on the leaf nodes of the second Merkel tree, so as to use the root node of the second Merkel tree as the second Merkel tree root associated with the N1 first contract addresses and the N2 second contract addresses.

[0146] For further understanding, please visit Figure 7 , Figure 7 This is another scenario diagram for determining the Merkle tree root provided by the embodiment of this application. For ease of understanding, N contract addresses are used as the above Figure 4 The contract address D1, contract address D2, contract address D3 and contract address D4 in the corresponding embodiment are taken as an example to illustrate how to determine the second Merkle root (for example, Figure 7 Specific process of calculating the hash value on node 73a in the Merkle tree 700a shown in FIG.

[0147] Among them, the N1 contract address among the N contract addresses can be Figure 7 The contract address D1 and contract address D4 shown in the figure, the N2 contract address in the N contract addresses can be Figure 7 The contract address D2 and contract address D3 are shown. Among them, the N1 resource management contracts corresponding to the N1 first contract addresses can be the resource management contract corresponding to the contract address D1 (for example, resource management contract Con1) and the resource management contract corresponding to the contract address D4 (for example, resource management contract Con4). The N2 resource management contracts corresponding to the N2 second contract addresses can be the resource management contract corresponding to the contract address D2 (for example, resource management contract Con2) and the resource management contract corresponding to the contract address D3 (for example, resource management contract Con3).

[0148] like Figure 7 As shown, the chain identifier (i.e., the first chain identifier) corresponding to the contract address D1 and the chain identifier (i.e., the first chain identifier) corresponding to the contract address D4 are both chain L1. Here, chain L1 (i.e., the first chain identifier) can specifically be the chain identifier of the first blockchain, which means that the resource management contract Con1 corresponding to the contract address D1 and the resource management contract Con4 corresponding to the contract address D4 are both deployed on the first blockchain; similarly, the chain identifier (i.e., the second chain identifier) corresponding to the contract address D2 and the chain identifier (i.e., the second chain identifier) corresponding to the contract address D3 are both chain L2. Here, chain L2 (i.e., the second chain identifier) can specifically be the chain identifier of the second blockchain, which means that the resource management contract Con2 corresponding to the contract address D2 and the resource management contract Con3 corresponding to the contract address D3 are both deployed on the second blockchain.

[0149] like Figure 7As shown, in an embodiment of the present application, the resource service device can determine, based on the four contract addresses (i.e., contract address D1, contract address D2, contract address D3, and contract address D4), that the chain identifiers of the two resource management contracts corresponding to two of the four contract addresses (e.g., contract address D1 and contract address D4) are chain L1, and the chain identifiers of the other two resource management contracts corresponding to the other two contract addresses (e.g., contract address D2 and contract address D3) are chain L2. Then, the two contract addresses (e.g., contract address D1 and contract address D4) of the four contract addresses can be collectively referred to as first-chain contract addresses, and the chain identifier L1 here can be concatenated with each of the two first-chain contract addresses to obtain Figure 7 The first address splicing information of each first chain contract address is shown. For example, the first address splicing information of contract address D1 can be Figure 7 As shown in P11, the first address splicing information of the contract address D4 can be Figure 7 Similarly, in the embodiment of the present application, the other two contract addresses (for example, contract address D2 and contract address D3) of the four contract addresses can be collectively referred to as the second chain contract address, and the chain identifier L2 here is spliced with each of the two second chain contract addresses to obtain Figure 7 The second address splicing information of each second chain contract address is shown. For example, the second address splicing information of the contract address D2 can be Figure 7 The second address concatenation information of the contract address D3, P22, can be Figure 7 P23 shown.

[0150] It should be understood that Figure 7 As shown, in the embodiment of the present application, a Merkle tree (i.e., a second Merkle tree, for example, Figure 7 When constructing the Merkle tree 700a shown in FIG5 , the hash value of the address splicing information of each of the four contract addresses (for example, the first address splicing information and the second address splicing information) is used as the node of the Merkle tree 700a to ensure that the Merkle path (that is, the Merkle Path) provided when the corresponding resource management contract (that is, the target resource management contract) is subsequently called on the target consensus node (for example, the first consensus node and the second consensus node) for contract verification does not directly contain the contract address of the resource management contract on other chains.

[0151] for example, Figure 7 The leaf nodes of the Merkle tree 700a (i.e., the second Merkle tree) shown specifically include Figure 7 Node 71a, node 71b, node 71c and node 71d are shown. Among them, the hash value on node 71a (i.e. Figure 7 H(P11)) is the first address concatenation information of the contract address D1 (i.e. Figure 7 The first address hash value obtained after hash calculation (ie, hash transformation) is performed on P11 shown in FIG. Similarly, the hash value on node 71d (ie, Figure 7 H(P14)) is the first address concatenation information of the contract address D4 (i.e. Figure 7 The first address hash value is obtained after performing hash calculation (ie, hash transformation) on P14).

[0152] In addition, if Figure 7 As shown, the hash value on node 71b (i.e. Figure 7 H(P22)) is the second address concatenation information of the contract address D2 (i.e. Figure 7 The second address hash value obtained after hash calculation (ie, hash transformation) of P22 shown in FIG. 1 is obtained; similarly, the hash value on node 71c (ie, Figure 7 H(P23)) is the second address concatenation information of the contract address D3 (i.e. Figure 7 The second address hash value is obtained after performing hash calculation (ie, hash transformation) on P23 shown in FIG.

[0153] It is understandable that in the embodiment of the present application, in the process of constructing the second Merkle tree (for example, Merkle tree 700a) based on the address hash value corresponding to the address splicing information of each contract address (for example, the first address hash value and the second address hash value), the hash value on node 71a and the hash value on node 71b can be hashed and spliced, and then the hash splicing value obtained by the hash splicing can be hashed again to obtain Figure 7 The hash value of node 72a shown in FIG. 1 is H(12). Similarly, the embodiment of the present application can perform hash concatenation on the hash value of node 71c and the hash value of node 71d, and then perform hash calculation again on another hash concatenation value obtained by hash concatenation to obtain Figure 7 The hash value of node 72b shown in FIG. 3 (i.e., H(34)) is obtained. Similarly, in the embodiment of the present application, the hash value of node 72a and the hash value of node 72b can be hashed together, and then the hashed value obtained by the hashing can be hashed again to obtain Figure 7 The hash value on the node 73a shown (ie, H(1234)), and the root node of the resulting Merkle tree 700a (eg, Figure 7 The hash value (i.e., H(1234)) on node 73a) shown is used as the second Merkle tree root associated with these four contract addresses.

[0154] Optionally, it can be understood that, in an embodiment of the present application, the management terminal associated with the M approval terminals can also be a second management terminal. The second management terminal here can specifically be a target approval terminal among the M approval terminals. For example, in an embodiment of the present application, any one of the M approval terminals can be used as the target approval terminal, or the approval terminal with the longest online time and the largest number of approval signatures among the M approval terminals can be used as the target approval terminal.

[0155] Therefore, when the target approval terminal is used as the second management terminal, the target approval terminal can be an approval terminal with access rights to the resource business service system among the M approval terminals, and the approval object corresponding to the target approval terminal can also be the above-mentioned management object. For example, the management object here can specifically be the above-mentioned Figure 2 The corresponding embodiment is user U1.

[0156] At this time, the specific process of the resource service device executing the above step S101 can also be described as: the resource service device can receive a second management request sent by the target approval terminal; the second management request here can be generated by the target approval terminal in response to the centralized modification operation performed on the N contract addresses on the business service page, based on the modification business event corresponding to the centralized modification operation; the business service page here can be provided by the approval object corresponding to the target approval terminal (for example, the above-mentioned user U1) when accessing the resource business service system based on access rights; further, the resource service device can configure the space operation serial number corresponding to the centralized modification operation based on the second management request; further, the resource service device can obtain the Merkle tree root associated with the N contract addresses, and can use the Merkle tree root, the space operation serial number, the modification timestamp corresponding to the modification business event, and the modification business event as the first signature content to be signed, so that the space management request associated with the N contract addresses can be determined based on the first signature content.

[0157] It should be understood that in the embodiment of the present application, the specific implementation method of the approval object corresponding to the target approval terminal to obtain the N contract addresses that need to be uniformly managed through the business service page can be found in the above Figure 2 or Figure 4 The description of the specific process of selecting N contract addresses in the corresponding embodiment will not be repeated here. Similarly, the specific implementation method of the resource service device in configuring the spatial operation sequence number of this centralized modification operation based on the second management request can be found in the above Figure 5 The description of the specific process of determining the spatial operation sequence number in the corresponding embodiment will not be repeated here. Similarly, the specific implementation method of the resource service device determining the Merkle tree root associated with the N contract addresses here can be found in the above Figure 6or Figure 7 The description of the specific process of determining the Merkle tree root in the corresponding embodiment will not be repeated here.

[0158] Step S102: Sending a space management request to M approval terminals associated with the business space, so that the M approval terminals perform approval signatures on the first signature content to obtain approval signature information for the first signature content; M is a positive integer greater than 1;

[0159] It should be understood that in the embodiment of the present application, each of the M approval terminals belongs to the approval terminal cluster associated with the business space. For example, when the business space is the above-mentioned space S1, the M approval terminals associated with the business space can specifically be the above-mentioned space S2. Figure 2 The corresponding embodiment deploys each approval terminal in the approval terminal cluster Q1.

[0160] Optionally, it is understood that when the business space is other spaces, the M approval terminals associated with other spaces may also be individual approval terminals deployed in other approval terminal clusters. Figure 8 , Figure 8 This is a schematic diagram of a scenario for sending space management requests to approval subjects in different approval groups, provided in an embodiment of the present application. It should be understood that in this embodiment of the present application, each approval terminal in an approval terminal cluster associated with a business space can belong to a maximum of M approval groups. For example, the same approval group can include one or more of the M approval terminals. The number of approval terminals for each approval subject included in each approval group is not limited.

[0161] For ease of understanding, Figure 8 As shown, here we take two approval groups as an example. These two approval groups can be Figure 8 The approval group 8a and the approval group 8b are shown. The approval group 8a may include three approval terminals corresponding to three approval objects (ie, three approvers), while the approval group 8b may include two approval terminals corresponding to two approval objects (ie, two approvers).

[0162] It is understandable that the resource service device, based on the first signature content (ie Figure 8 After the signature content B2 shown generates a space management request associated with N contract addresses (for example, the 4 contract addresses selected in the above space S3), the current business space (for example, Figure 8The M approval terminals are associated with the space S3 shown in FIG. 8 . The M approval terminals may specifically include approval terminal 81a, approval terminal 81b, and approval terminal 81c in approval group 8a, and approval terminal 82a and approval terminal 82b in approval group 8b.

[0163] For ease of understanding, in this application embodiment, among the M approval terminals, the approval terminals in the approval group 8a (for example, the approval terminal 81a, the approval terminal 81b, and the approval terminal 81c) may be collectively referred to as the first approval terminal, and the approval terminals in the approval group 8b (for example, the approval terminal 82a and the approval terminal 82b) may be collectively referred to as the second approval terminal.

[0164] Among them, the approval address of the approval object (i.e., the approver) corresponding to the first approval terminal can be the first approval address. Similarly, the approval address of the approval object (i.e., the approver) corresponding to the second approval object can be the second approval address. Here, the first approval address and the second approval address are both on-chain registration addresses after the address is registered on the blockchain (for example, the above-mentioned first blockchain).

[0165] Among them, such as Figure 8 As shown, the modified business event in the signature content B1 can specifically refer to adding an approver with the approval address A5 to different contract addresses in space S3 (for example, the above-mentioned contract address D5, contract address D6, contract address D7 and contract address D9). In other words, in this embodiment of the application, the modified business event at least includes the action of adding an approval object and the parameter of adding an approval address; wherein, the action of adding an approval object refers to adding a business approval object for the approval signature to N contract addresses (for example, Figure 8 The approval address shown is the approver of A5), and the approval address parameter is the third approval address of the business approval object (for example, the approval address A5). Figure 8 In the signature content B2 shown, the third approval address (for example, approval address A5) that needs to be approved is the approval address to be registered on the corresponding blockchain (for example, the first blockchain mentioned above). Figure 8 As shown, the signature content B1 carries the Merkle tree root of these N contract addresses (for example, Figure 8 Root3) instead of using the individual contract addresses directly. This means Figure 8The approval terminals in each approval group shown actually need to approve the signature of the Merkle tree root of the N contract addresses, rather than directly approving each of the N contract addresses. That is, for each approval terminal involved in the embodiment of the present application, it is only necessary to approve the signature of the Merkle tree root of the N contract addresses once, thereby avoiding the phenomenon of N approval signatures traversing each directly received contract address. This not only improves the signature efficiency of the approval signature from the root, but also ensures that the resource service device can quickly obtain the approval signature information associated with the M approval terminals, thereby improving the efficiency of constructing the signature transaction for submission to the corresponding consensus node on the chain.

[0166] like Figure 8 As shown, when the approval terminal under each approval group obtains the space management request, it can parse the space management request to obtain the signature content to be signed (for example, Figure 8 At this time, the approval object corresponding to the approval terminal in each approval group can use the private key corresponding to the approval address registered on the corresponding blockchain (for example, the first blockchain mentioned above) to approve the signature content B2 carried in the space management request to obtain the approval signature information for the signature content B2.

[0167] For example, in the multi-signature process, the approval object corresponding to any approval terminal in the approval group 8a can approve the signature content B2 using its own private key. Therefore, in the embodiment of the present application, the resource service device 80b can, upon receiving the approval signature information of the approval object corresponding to a certain approval terminal in the approval group 8a (for example, the approval terminal 81a), send the task status of the content approval task for the content approval of the signature content B2 to each approval terminal in the approval group 8a (for example, the approval terminal 81a, the approval terminal 81b, and the approval terminal 81c) as a task completion status. In this way, the approval objects corresponding to other approval terminals in the approval group 8a (for example, the approval terminal 81b and the approval terminal 81c) do not need to repeatedly approve the signature content B2. In this way, the signature efficiency of different approval objects in the same approval group approving the same signature content can be improved in the approval group 8a.

[0168] For another example, during the multi-signature process, the approval object corresponding to any approval terminal in the approval group 8b can also approve the signature content B2 using its own private key. Therefore, in the embodiment of the present application, the resource service device 80b can, upon receiving the approval signature information of the approval object corresponding to an approval terminal (for example, approval terminal 82a) in the approval group 8b, send the task status of the content approval task for the content approval of the signature content B2 to each approval terminal (for example, approval terminal 82a and approval terminal 82b) in the approval group 8b as a task completion status. In this way, the approval objects corresponding to other approval terminals (for example, approval terminal 82b) in the approval group 8b do not need to repeatedly approve the signature content B2. In this way, the signature efficiency of different approval objects in the same approval group approving the same signature content can also be improved in the approval group 8b.

[0169] It should be understood that in the embodiment of the present application, after any one of the approval objects in each approval group completes the approval signature for the same signature content, step S103 can be executed to return the obtained approval signature information for the signature content B2 to the resource service device (for example, Figure 8 The resource service device 80b is shown.

[0170] Step S103: Acquire the approval signature information returned by the M approval terminals. Based on the acquired approval signature information, construct a first approval signature list associated with the M approval terminals, and determine the first Merkle path from the contract address i to the Merkle tree root.

[0171] Wherein, the blockchain includes a first blockchain; the M approval terminals include a first approval terminal and a second approval terminal, the approval address of the first approval terminal is the first approval address, and the approval address of the second approval terminal is the second approval address, and the first approval address and the second approval address are both on-chain registered addresses after the address is registered on the first blockchain; modifying a business event at least includes an approval object addition action and an approval address addition parameter; the approval object addition action refers to the centralized addition of a business approval object for approval signatures to N contract addresses, and the approval address addition parameter is the third approval address of the business approval object; the third approval address is the approval address to be registered on the first blockchain. At this time, the specific implementation method of the resource service device executing step S103 can be described as follows: the resource service device can receive the first approval signature information returned by the first approval terminal; the first approval signature information here can be the first approval terminal, when obtaining the first signature content based on the space management request, adding an action to the approval object, adding a parameter to the approval address, and performing content approval on the Merkle tree root in the first signature content, and when the content approval is completed, the first signature content is approved and signed by the first private key corresponding to the first approval address; wherein, the first approval terminal here can specifically be the above-mentioned Figure 8 In the corresponding embodiment, any approval terminal is located in the approval group 8a. At the same time, it can be understood that the resource service device can receive the second approval signature information returned by the second approval terminal; the second approval signature information here can be specifically obtained by the second approval terminal adding an action to the approval object in the first signature content, adding parameters to the approval address, and performing content approval on the Merkle tree root when the second approval terminal obtains the first signature content based on the space management request, and when the content approval is completed, the second private key corresponding to the second approval address is used to approve the first signature content; the second private key is different from the first private key; wherein, the second approval terminal can be specifically the above-mentioned Figure 8 The corresponding embodiment is any one of the approval terminals in the approval group 8b. Further, the resource service device can determine the approval signature information returned by each approval terminal based on the first approval signature information and the second approval signature information.

[0172] Optionally, it is understood that in the embodiment of the present application, in order to ensure the security and reliability of the approval signature, the embodiment of the present application can also receive the same signature content (for example, the above-mentioned Figure 8The approval signature information of the signature content B2) shown in the figure can be filtered out from the received approval signature information when the current time reaches the approval signature time, so as to establish an approval signature list associated with M approval terminals (for example, the first approval signature list), so that step S104 can be further executed when the Merkle path of a certain contract address (for example, contract address i among N contract addresses) is determined.

[0173] It is understood that, in the case where N contract addresses are 4 contracts selected from space S3, these 4 contract addresses can be specifically the above Figure 6 The corresponding embodiment of the contract address D5, contract address D6, contract address D7 and contract address D9. In the embodiment of this application, the contract address i here can be any one of the four contract addresses. For ease of understanding, here we take the contract address i as the above-mentioned contract address D5 as an example. At this time, the Merkle path of the contract address D5 can be from the contract address D5 to Figure 8 The first Merkle path of the Merkle root (e.g., node 63a) in the Merkle tree 600a shown. In the Merkle tree 600a, the nodes involved in the Merkle path (e.g., Path5) of the contract address D5 may specifically include the above Figure 6 Node 61a, node 62a and node 63a are shown. Node 62a can be considered as the parent node of node 61a. Similarly, node 63a can be considered as the parent node of node 62a. Similarly, in the Merkle tree 600a, the nodes involved in the Merkle path (e.g., Path6) of the contract address D6 can specifically include the above Figure 6 Node 61b, node 62a and node 63a are shown. Similarly, in the Merkle tree 600a, the nodes involved in the Merkle path (e.g., Path7) of the contract address D7 may specifically include the above Figure 6 Node 61c, node 62b and node 63a are shown. Similarly, in the Merkle tree 600a, the nodes involved in the Merkle path (e.g., Path9) of the contract address D9 may specifically include the above Figure 6 Node 61d, node 62b and node 63a are shown.

[0174] It should be understood that for the method of determining the Merkle path of other contract addresses in these N contracts (for example, contract address D6, contract address D7, and contract address D9), please refer to the description of the specific process of determining the Merkle path of contract address D5, which will not be further elaborated here.

[0175] Step S104: Obtain the first operation private key of the operation object i. When a first signed transaction is constructed based on the first operation private key, the first signature content, the first Merkle path, and the first approval signature list, the first signed transaction is sent to the first consensus node running the resource management contract i.

[0176] Among them, the first consensus node is used to verify the first signature transaction through the first operation public key corresponding to the first operation private key, and when the transaction verification is successful, the first signature transaction is verified through the resource management contract i, and when the transaction verification is successful, the resource management contract i is called to execute the modification business event; the transaction verification includes root verification of the Merkle tree root based on the first Merkle path and multi-signature verification of the first approval signature list.

[0177] Wherein, the blockchain includes a first blockchain, the resource management contract i corresponding to the contract address i is deployed on the first blockchain, the consensus node on the first blockchain is the first consensus node, the operation service component corresponding to the operation object i is deployed in the resource service device, and the operation terminal corresponding to the operation object i is the operation terminal i. At this time, the specific process of the resource service device executing step S104 can be described as: the resource service device can determine the operation service component corresponding to the operation object i as the operation service component i, and use the first signature content, the first Merkel path and the first approval signature list as the transaction content of the first transaction to be signed through the operation service component i. When the first transaction to be signed is constructed based on the transaction content, a transaction signature request for the first transaction to be signed is sent to the operation terminal i; the transaction signature request is used to instruct the operation terminal i to generate a signature authorization instruction corresponding to the signature authorization operation in response to the signature authorization operation for the first transaction to be signed; further, the resource service The device can receive the signature authorization instruction returned by the operation terminal i, so that the first operation private key of the operation object i can be obtained from the resource business service system based on the signature authorization instruction; further, the resource service device can use the first operation private key of the operation object i to sign the first transaction to be signed to obtain transaction signature information for the first transaction to be signed; further, the resource service device can construct a first signature transaction corresponding to the operation service component i based on the first transaction to be signed and the transaction signature information, and can send the first signature transaction to the first consensus node, so that when the first consensus node obtains the first operation public key corresponding to the first operation private key, it can verify the first signature transaction through the first operation public key, and when the transaction verification is successful, the resource management contract corresponding to the contract address i is used to verify the first signature transaction, and when the transaction verification is successful, the resource management contract corresponding to the contract address i is called to execute the modification business event.

[0178] For further understanding, please see Figure 9 , Figure 9 This is a schematic diagram of a scenario for constructing a signature transaction provided by an embodiment of the present application. In the embodiment of the present application, a contract address may correspond to a resource management contract on a certain blockchain, where the blockchain may be the first blockchain mentioned above, and the chain identifier of the first blockchain may be specifically Figure 9 The chain L1 shown here means Figure 9 The resource service device 90b shown in FIG. 1 is configured to receive the current contract address (ie, contract address i, for example, Figure 9 The operation service component (i.e., operation service component i, for example, operation service component 5) corresponding to the contract address D5 shown in FIG1 constructs a signed transaction (for example, Figure 9 When the signature transaction TX5 shown is generated, the currently constructed signature transaction (for example, Figure 9 The signed transaction TX5 is submitted to the first consensus node on the first blockchain. Figure 9 As shown, the resource management contract i corresponding to the contract address i deployed on the first blockchain (for example, Figure 9 The resource management contract Con5 corresponding to the contract address D5 shown can run on the first consensus node.

[0179] The specific process of the resource service device 90b constructing the signature transaction TX5 (i.e., the first signature transaction) by operating the service component can be described as follows: the resource service device 90b can pre-set the signature transaction TX5 by operating the service component 5. Figure 9 The Merkle root shown (i.e., the first Merkle root, which can be specifically Figure 9 The signature content B2 (i.e., the first signature content) of H(5679) shown in FIG. 1 and the first Merkle path (i.e., Figure 9 The path Path5 shown here specifically refers to a path from the tree node of the Merkle tree corresponding to the contract address D5 in the above space S3 to the root node where the first Merkle tree root is located), and the first approval signature list (for example, Figure 9 The list R) shown is used as the transaction content of the first transaction to be signed.

[0180] The transaction content of the first transaction to be signed can be Figure 9The transaction content T5 shown in FIG. 5 may include a modification business event triggered for N contract addresses, a space operation sequence number and modification operation timestamp uniquely identifying the centralized modification operation on the N contract addresses, a list of approval signatures, and a Merkle path for a contract address (i.e., contract address i, e.g., contract address D5) among the N contract addresses. Specifically, the N contract addresses may be the four contract addresses selected by the user U2 (i.e., the management object) in the business space (e.g., space S3). The blockchain containing the four resource management contracts corresponding to these four contract addresses may be the first blockchain identified by chain L1.

[0181] It is understandable that when the resource service device 90b constructs the transaction content T5, it can further perform step S31 to Figure 9 The transaction content T5 shown is constructed to obtain the first transaction to be signed (for example, Figure 9 Further, the resource service device 90b can execute Figure 9 Step S32 is shown to be for the first transaction to be signed (for example, Figure 9 The transaction signature request for the transaction to be signed T5') is sent to Figure 9 The operation terminal 90a shown here can be the above-mentioned contract address i (for example, Figure 9 The contract address D5 shown in the figure corresponds to the resource management contract i (for example, Figure 9 The resource management contract Con5 shown in FIG5 is configured by the operation object i (for example, Figure 9 The operator U3 shown in the figure) corresponds to the operation terminal i; it can be understood that the transaction signature request here is used to instruct the operator U3 to Figure 9 The display interface 900a shown is for the first transaction to be signed (ie Figure 9 The transaction to be signed T5') triggers the authorization operation, so that the Figure 9 The illustrated operating terminal 90a may respond to a request for a first transaction to be signed (i.e. Figure 9 The signature authorization operation of the transaction to be signed T5') shown in FIG5 can generate a signature authorization instruction corresponding to the signature authorization operation; further, as shown in FIG5 Figure 9 As shown, the operation terminal 90a may return the signature authorization instruction corresponding to the signature authorization operation to the resource service device 90b when executing step S33.

[0182] In this way, when the resource service device 90b receives the signature authorization instruction returned by the operation terminal 90a, it can further obtain the first operation private key entrusted and stored by the operator U3 from the resource business service system based on the signature authorization instruction; further, the resource service device 90b can execute step S34, so that the first transaction to be signed (i.e., the first operation private key of the operation object i) can be used to obtain the operation private key of the operator U3 (i.e., the first operation private key of the operation object i). Figure 9 The resource service device 90b can then construct a signature transaction TX5 (i.e., a first signature transaction) corresponding to the operation service component 5 based on the first transaction to be signed and the transaction signature information, thereby submitting the currently constructed signature transaction TX5 (i.e., the first signature transaction) to the first consensus node on the first blockchain, so that the first consensus node can execute the resource management contract corresponding to the contract address D5. Figure 9 Contract verification steps for the shown pair.

[0183] Among them, such as Figure 9 As shown, (1) the first consensus node can calculate the address hash value of the current contract address (i.e., contract address D5). (2) The first consensus node can quickly index the Merkle tree constructed by the above four contract addresses based on the address hash value of the contract address D5 (e.g., the above Merkle tree 600a). In this way, the first consensus node can quickly obtain the associated verification node associated with the tree node where the contract address D5 is located based on the Merkle path of the contract address D5 (e.g., the above Figure 6 The node 61b corresponding to the contract address D7 shown in the figure, the node 62b above), and then the address hash value of the contract address D5 calculated in step (1) can be, for example, the key node on the Merkle path where the contract address D5 is located (for example, the key node above Figure 6 The Merkle root of the new Merkle tree is reconstructed by comparing the recalculated Merkle root with the original Merkle root on the Merkle path of the contract address D5. The root verification result is obtained. It should be understood that the root verification here is mainly used to determine whether the recalculated Merkle root is consistent with the original Merkle root. If they are consistent, the root verification is determined to be successful, and the verification result when the verification is successful can be used as the root verification result.

[0184] like Figure 9As shown, (3) the first consensus node can restore the approval signature information through the transaction parameters in the signature transaction TX5. The approval signature information here can specifically be the approval signature information of the approval objects in each approval group that constitutes the above-mentioned approval signature list, and then the restored approval signature information can be multi-signature verified to obtain a multi-signature verification result. The multi-signature verification result here is mainly used to determine whether the number of signatures of the approval signature information in the approval group reaches the preset multi-signature threshold. If it reaches, it can be determined that the centralized modification operation triggered by the above-mentioned management object for the N contract addresses in the business space is a legal operation. At this time, (4) the first consensus node can determine that the transaction verification result obtained by performing transaction verification on the signature transaction TX5 can be the result when the transaction verification is successful, if it is determined that this centralized modification operation is a legal operation. At this time, the first consensus node can execute the modification operation referred to by this modification business event through the resource management contract Con5 corresponding to the current contract address D5. The modification operation here can include the above-mentioned approver's new operation.

[0185] Optionally, in the embodiment of the present application, the modification operation here (ie, the above-mentioned centralized modification operation) may also include the above-mentioned approver removal operation.

[0186] For example, here we still take the blockchain including the first blockchain as an example; the approval address of each approval terminal in the M approval terminals is the on-chain registration address after the address is registered on the first blockchain, wherein the M approval terminals may specifically include approval terminal m, m is a positive integer less than or equal to M, at this time, the modification business event executed by the first consensus node calling the above-mentioned contract address i (for example, contract address D5) may also include at least an approval object removal action and an approval address removal parameter; wherein the approval object removal action refers to the centralized removal of the approval terminal m used for approval signature for the N contract addresses (for example, the approval terminal m may be the above-mentioned Figure 2 The corresponding approval terminal 120b in the embodiment) corresponds to the approval object (for example, the above Figure 2 The approval address removal parameter is used to indicate that the approval address of the approval object corresponding to the approval terminal m is removed on the first blockchain (for example, the above Figure 2 The approval address of user U21 is shown).

[0187] It can be seen that the resource service device involved in the embodiment of the present application can be a computer device in a resource business service system. The resource business service system here may include a resource service device for providing address management services, and multiple approval terminals for jointly managing different contract addresses in a certain space (i.e., business space) (i.e., M approval terminals, M is a positive integer greater than 1. For ease of understanding, here we take each of the M approval terminals as an example and take it as an example that each approval terminal belongs to an approval group). In the embodiment of the present application, the business space records multiple contract addresses including at least the above-mentioned N contract addresses. Each contract address in the N contract addresses corresponds to a resource management contract on a certain blockchain. For ease of understanding, here we take the contract address i in the N contract addresses as an example. The resource management contract corresponding to the contract address i is the resource management contract i on the blockchain, and the operation object corresponding to the contract address i is the operation object i. It should be understood that in an embodiment of the present application, when the resource service device receives a space management request associated with N contract addresses in the business space, it can further distribute the space management request to M approval terminals associated with the business space. One approval object can correspond to one approval terminal. When one approval terminal is included in an approval group, the number of approval groups to which these M approval terminals belong can be at most M. Furthermore, when each of these M approval terminals receives a space management request carrying the same signature content (i.e., the first signature content), it can perform an approval signature on the same signature content (i.e., the first signature content) to obtain approval signature information for the same signature content (i.e., the first signature content), and then return the approval signature information in which it participated in the approval signature to the resource service device. It should be understood that in an embodiment of the present application, the first signature content here can at least include the Merkle tree root associated with the N contract addresses and the modification business event triggered for the N contract addresses. In other words, the embodiment of the present application can be based on the spatial concept of business space, so that when the approval object corresponding to each approval terminal approves and signs the same signature content (that is, the first signature content), it only needs to approve and sign the same signature content (that is, the Merkle root directly carried in the first signature content) once. This can enable each approval object to indirectly approve and sign multiple different contract addresses associated with the Merkle root, without the need for each approval object to directly approve and sign these different contract addresses separately. This means that the embodiment of the present application directly uses the Merkle root in the first signature content instead of directly using N contract addresses, so there is no need to approve and sign each of the N contract addresses separately. In this way, the efficiency of approving and signing different contract addresses in the same business space can be effectively improved.In addition, it can be understood that after collecting the approval signature information of these approval terminals, the resource service background can quickly construct a first approval signature list for multi-signature verification, and then can construct a signature transaction to be submitted to the blockchain (for example, the above-mentioned first signature transaction) through the operation private key of the operation object (for example, the above-mentioned operation object i) corresponding to the corresponding resource management contract (for example, the above-mentioned resource management contract i). This means that for the consensus node (that is, the above-mentioned first consensus node) running the corresponding resource management contract (for example, the above-mentioned resource management contract i) on a certain blockchain, it can accurately call the corresponding resource management contract (for example, the above-mentioned resource management contract i) after performing transaction verification (for example, root verification and multi-signature verification) to execute the modification business event for the corresponding contract address (that is, contract address i) among these N contract addresses, thereby improving the efficiency of address management of different contract addresses in the same business space.

[0188] For further information, see Figure 10 , Figure 10 This is a data processing method based on blockchain provided by an embodiment of the present application. The method is executed by a resource service device in a resource business service system. The resource service device here can be the above-mentioned Figure 2 The business space of the resource business service system in the corresponding embodiment includes N contract addresses, where N is a positive integer greater than 1. The N contract addresses include contract address i, the operation object corresponding to contract address i is operation object i, and the resource management contract corresponding to contract address i is resource management contract i on the blockchain, where i is a positive integer less than or equal to N. Figure 10 As shown, the method may at least include steps S201 to S210.

[0189] Step S201: Obtain space management requests associated with N contract addresses;

[0190] The first signature carried in the space management request includes the Merkle tree root associated with N contract addresses and the modification business event triggered for the N contract addresses;

[0191] Among them, it should be noted that in the embodiment of the present application, in the process of address management of the resource service device, under the concept of "space" of the business space composed of different contract addresses, there is a certain management object (for example, any one of the first management object and the second management object mentioned above) that needs to perform centralized modification operations on (many) contract addresses that may exist in a space. For example, there may be a certain approver among the M approvers (that is, the second management object mentioned above) who needs to perform unified management and modification operations on multiple contracts under the space (such as batch increase and decrease of approvers). At this time, the resource service device can calculate the Merkle tree roots of these contract addresses (for example, the 4 contract addresses selected from space S1) in units of space. In this way, when the subsequent resource service device generates a space management request carrying the first signature content, it can ensure that the first signature content that needs to be signed specifically contains the Merkle tree roots of these N contract addresses, rather than these N contract addresses. This means that for each of the M approvers corresponding to the M approval terminals subsequently associated with the business space, it is only necessary to make one approval signature for the Merkle tree root managed by the N contract addresses under the business space, without the need for multiple approval signatures for each of the N currently selected contract addresses. Thus, it can be seen that, compared with the current signature design scheme in which each resource management contract is an independent contract, the embodiment of the present application can improve the signature efficiency during the approval signature through the space-level signature design scheme based on the Merkle tree root here, thereby fundamentally improving and optimizing the approval signature experience of each approver by reducing the number of approval signatures. At the same time, the space-level signature design scheme can also be used to quickly construct a signed transaction for each contract address. In this way, in the process of writing the signed transactions of these contract addresses to the corresponding blockchain (for example, the above-mentioned target chain), the root verification of the Merkle tree root here can be implemented through the Merkle path of each contract address, and the address validity of the target contract address (for example, contract address i) among the N contract addresses in the current business space can be quickly determined by the root verification success result obtained during the root verification. In addition, the embodiment of the present application emphasizes that when the transaction verification of the signature verification is successful, the target resource management contract (for example, resource management contract i) corresponding to the target contract address (for example, contract address i) can be called to execute the modification business event here, thereby eliminating the need to frequently call the resource management contract during the contract call process, thereby reducing the cost of calling the resource management contract during the signature transaction chain.

[0192] Step S202: Send a space management request to M approval terminals associated with the business space, so that the M approval terminals perform approval signatures on the first signature content to obtain approval signature information for the first signature content; M is a positive integer greater than 1;

[0193] The specific implementation method of M approval terminals for approving and signing the first signature content can be found in the above Figure 3 The description of the specific process of the approval signature in the corresponding embodiment will not be repeated here.

[0194] Step S203: Acquire the approval signature information returned by the M approval terminals. Based on the acquired approval signature information, construct a first approval signature list associated with the M approval terminals, and determine the first Merkle path from the contract address i to the Merkle tree root.

[0195] Among them, the specific implementation method of the resource service device to construct the first approval signature list can be found in the above Figure 3 The specific process of obtaining the first approval signature list in the corresponding embodiment will not be described here. In addition, the method for determining the first Merkle path of the contract address i can refer to the above Figure 3 The description of the specific process of determining the Merkle path of the contract address D5 (i.e., the above-mentioned Path5) in the corresponding embodiment will not be repeated here.

[0196] Step S204: Obtain the first operation private key of the operation object i. When a first signed transaction is constructed based on the first operation private key, the first signature content, the first Merkle path, and the first approval signature list, the first signed transaction is sent to the first consensus node running the resource management contract i.

[0197] Among them, the first consensus node is used to verify the first signature transaction through the first operation public key corresponding to the first operation private key, and when the transaction verification is successful, the first signature transaction is verified through the resource management contract i, and when the transaction verification is successful, the resource management contract i is called to execute the modification business event; the transaction verification includes root verification of the Merkle tree root based on the first Merkle path and multi-signature verification of the first approval signature list.

[0198] Among them, modifying the business event at least includes the action of adding an approval object and the parameter of adding an approval address; the action of adding an approval object refers to centrally adding a business approval object for approval signature to N contract addresses, and the parameter of adding the approval address is the third approval address of the business approval object; the third approval address is the approval address to be registered on the first blockchain; the first consensus node is used to add the approval management relationship between the business approval object and the contract address i when calling the resource management contract i to execute the modification business event, and when the first signature transaction carrying the third approval address is chained to the first blockchain based on the approval management relationship, the modification success event information carrying the approval management relationship is recorded through the resource management contract i; at this time, the resource service device can further execute steps S205-step S210.

[0199] It should be understood that in the embodiment of the present application, these N contract addresses can also be the above Figure 7 The management objects in the corresponding embodiment are four contract addresses (for example, contract address D1, contract address D2, contract address D3, and contract address D4) selected from space S1 (i.e., business space). For ease of understanding, the blockchain is taken as an example including a first blockchain and a second blockchain, wherein the resource management contract corresponding to contract address i among the N contract addresses (i.e., resource management contract i) is deployed on the first blockchain, and the resource management contract corresponding to contract address k among the N contract addresses (i.e., resource management contract k) is deployed on the second blockchain. The consensus node on the first blockchain is the above-mentioned first consensus node, and the consensus node on the second blockchain is the second consensus node.

[0200] For example, as mentioned above Figure 7 As shown, the resource management contract corresponding to the contract address D1 (for example, the resource management contract Con1) and the resource management contract corresponding to the contract address D4 (for example, the resource management contract Con4) are both deployed on the first blockchain with the chain identifier chain L1 (i.e., the first chain identifier). The resource management contract corresponding to the contract address D2 (for example, the resource management contract Con2) and the resource management contract corresponding to the contract address D3 (for example, the resource management contract Con3) are both deployed on the second blockchain with the chain identifier chain L2 (i.e., the second chain identifier).

[0201] The specific implementation method of the resource service device submitting the first signature transaction to the first consensus node can be found in the above Figure 3 The description of the specific process of constructing and submitting the first signature transaction for contract address i (for example, the above-mentioned contract address D1) in the corresponding embodiment will not be repeated here.

[0202] Optionally, when executing the above step S204, the resource service device may also execute the following steps: wherein the blockchain includes a second blockchain different from the first blockchain, the N contract addresses include a contract address k, k is a positive integer less than or equal to N; the resource management contract corresponding to the contract address k is the resource management contract k, the resource management contract k is deployed on the second blockchain, the consensus node on the second blockchain is the second consensus node, and the operation object corresponding to the contract address k is the operation object k; at this time, the resource service device can determine the second Merkle path from the contract address k to the Merkle tree root; further, the resource service device can obtain the operation The second operation private key of object k, when constructing the second signature transaction based on the second operation private key, the first signature content, the second Merkle path and the first approval signature list, sends the second signature transaction to the second consensus node; the second consensus node is used to verify the second signature transaction through the second operation public key corresponding to the second operation private key, and when the transaction verification is successful, the second signature transaction is verified through the resource management contract k, and when the transaction verification is successful, the resource management contract k is called to execute the modification business event; the transaction verification includes root verification of the Merkle tree root based on the second Merkle path and multi-signature verification of the first approval signature list.

[0203] For further understanding, please see Figure 11 , Figure 11 This is a schematic diagram of a scenario in which a signed transaction is submitted to a target consensus node on a target chain, provided by an embodiment of the present application. Figure 11 The field value of the field Adrr1 shown can be the contract address 1 mentioned above, and the resource management contract corresponding to the contract address 1 (i.e. the resource management contract Con1 mentioned above) can be Figure 11 The resource management contract 1 shown in FIG. 1 ; wherein, Figure 11 The field value of the field Adrr2 shown can be the above-mentioned contract address 2, and the resource management contract corresponding to the contract address 2 (i.e. the above-mentioned resource management contract Con2) can be Figure 11 The resource management contract 2 shown in FIG. 2 ; wherein, Figure 11 The field value of the field Adrr3 shown can be the contract address 3 mentioned above, and the resource management contract corresponding to the contract address 3 (i.e. the resource management contract Con3 mentioned above) can be Figure 11 The resource management contract 3 shown in the figure is as follows: Figure 11 The field value of the field Adrr4 shown can be the contract address 4 mentioned above, and the resource management contract corresponding to the contract address 4 (i.e. the resource management contract Con4 mentioned above) can be Figure 11 The resource management contract 4 is shown.

[0204] Among them, such as Figure 11As shown, the resource service device can calculate the Merkle tree root associated with N contract addresses through the space management module 110a (for example, Figure 11 The hash value on the node 111a shown can be used as the Merkle root of the signature content in the signature management module 110b, namely Root). The Merkle calculation strategy of the Merkle root, namely Root, can be obtained by following the above Figure 3 The description of the first Merkel calculation strategy and the second Merkel calculation strategy in the corresponding embodiment will not be further elaborated here.

[0205] For ease of understanding, the chain identifier of the resource management contract 1 can be Figure 11 The chain ID of the field ChainID1 and resource management contract 2 shown can be Figure 11 The ChainID2 field shown in the figure shows the chain ID where the resource management contract 3 is located. Figure 11 The ChainID3 field and the chain identifier where the resource management contract 4 is located can be Figure 11 Take the ChainID4 field as an example, where the field value of the ChainID1 field can be the above Figure 7 The chain L1 shown, the field value of the field ChainID2 can be the above Figure 7 The chain L2 shown, the field value of the ChainID3 field can be the above Figure 7 The chain L2 shown in the figure, the field value of the ChainID4 field can be the above Figure 7 Chain L1 is shown.

[0206] in, Figure 11 The hash value (e.g., Hash(P1)) on the node 113a shown is the address hash value (i.e., the first address hash value) obtained by performing a hash transformation on the address splicing information (i.e., P1, e.g., the first address splicing information), where P1 is obtained by splicing the field value of the field Addr1 (e.g., the contract address D1) and the field value of ChainID1 (e.g., the chain L1). Figure 11 The hash value (e.g., Hash(P2)) on the node 113b shown is the address hash value (i.e., the second address hash value) obtained by performing a hash transformation on the address splicing information (i.e., P2, e.g., the second address splicing information), where P2 is obtained by splicing the field value of the field Addr2 (e.g., the contract address D2) and the field value of ChainID2 (e.g., the chain L2). Figure 11The hash value (e.g., Hash(P3)) on the node 113c shown is the address hash value (i.e., the second address hash value) obtained by performing a hash transformation on the address splicing information (i.e., P3, e.g., the second address splicing information), where P3 is obtained by splicing the field value of the field Addr3 (e.g., the contract address D3) and the field value of the ChainID3 (e.g., the chain L2). Figure 11 The hash value on the node 113d shown (e.g., Hash(P4)) is the address hash value (i.e., the above-mentioned first address hash value) obtained by performing a hash transformation on the address splicing information (i.e., P4, for example, the above-mentioned first address splicing information), wherein P4 is obtained by splicing the field value of the field Addr4 (e.g., the above-mentioned contract address D4) and the field value of ChainID4 (e.g., the above-mentioned chain L1).

[0207] Similarly, Figure 11 The hash value (e.g., Hash(12)) on the node 112a shown is obtained by hashing and transforming the hash value (e.g., Hash(P1)) on the node 113a and the hash value (e.g., Hash(P2)) on the node 113b. Figure 11 The hash value (e.g., Hash(34)) on node 112b shown is obtained by hashing and transforming the hash value (e.g., Hash(P3)) on node 113c and the hash value (e.g., Hash(P4)) on node 113d. Figure 11 The node 112a shown is the parent node of node 113a and node 113b, node 112b is the parent node of node 113c and node 113d, and node 111a is the parent node of node 112a and node 112b. That is, the hash value on node 111a (for example, Hash(1234)) refers to the hash value on node 112a (for example, Hash(12)) and the hash value on node 112b (for example, Hash(34)) obtained after hash concatenation and hash transformation.

[0208] Among them, resource service equipment can be Figure 11 The signature management module 110b shown in FIG. 1 constructs the signature content to be signed (for example, the first signature content mentioned above). The specific method for determining the first signature content can be referred to in the above Figure 3 The description of the first signature content in the corresponding embodiment will not be repeated here.

[0209] It should be understood that the resource service device can also construct the approval signature information after receiving the approval signature information returned by each approval terminal in the M approval terminals. Figure 11The approval signature list in the transaction content shown (i.e. the first approval signature list mentioned above, denoted as R). Figure 11 As shown, the signature management module 110b in the resource service device can construct the transaction content to be signed by the operation private key of different operation objects in the operation management module through the signature content (i.e., the above-mentioned first signature content), the approval signature list obtained by the various approval signature information for approving the first signature content, and the Merkle path of the target contract address among the N contract addresses (for example, the above-mentioned contract address i), and then construct the signed transaction for submission to the consensus node on the corresponding blockchain through each transaction content carrying different Merkle paths.

[0210] To facilitate the distinction, the embodiments of the present application can be based on Figure 11 The transaction structure of the transaction content shown in the figure distinguishes the Merkle paths representing each contract address. For example, Figure 11 As shown, the Merkle path associated with the field value of the field Addr1 (for example, the contract address D1) may be Path1, and the transaction content in Path1 may be the transaction content T1. It is understood that the operation management module 110c in the resource service device may dynamically configure the corresponding operation service component based on the currently selected N contract addresses.

[0211] It should be understood that the resource service device can further generate a signature transaction T1' based on the transaction content T1. Figure 11 The operation service component 1 shown sends a transaction signature request to the operation object configured for the resource management contract 1 (i.e., the above-mentioned operation object i, for example, operator 1). In this way, after the resource service device obtains the signature authorization instruction returned by the operation terminal corresponding to operator 1 (i.e., the above-mentioned operation terminal i), it can use the operation private key of operator 1 (i.e., the above-mentioned first operation private key) to sign the transaction T1' to be signed. Then, the transaction signature information obtained by the transaction signature and the transaction T1' to be signed can be used to construct Figure 11 The operation service component 1 (i.e., the above-mentioned service component i) corresponds to the signature transaction TX1 (i.e., the first signature transaction), so that the signature transaction TX1 (i.e., the first signature transaction) can be submitted to a certain blockchain (i.e., Figure 11 The target chain shown, for example, the target chain here is essentially a blockchain, and the target chain can specifically include the consensus node (i.e. Figure 11 The target consensus node shown, for example, the target consensus node here can be specifically the first consensus node mentioned above). The first consensus node is Figure 11The specific process of contract verification (i.e. the above transaction verification) from steps (1) to (4) shown above can be found in the above Figure 9 The description of the specific process of transaction verification by the first consensus node in the corresponding embodiment before executing the modification business event will not be repeated here.

[0212] For example, Figure 11 As shown, the Merkle path associated with the field value of the field Addr2 (i.e., the contract address k among the N contract addresses, for example, the contract address D2) can be Path2, and the transaction content in Path2 can be the above-mentioned transaction content T2. Then, when the transaction to be signed T2' containing the same signature content is constructed based on the transaction content T2, the resource service device can further Figure 11 The operation service component 2 shown sends a transaction signature request to the operation object (i.e., the above-mentioned operation object k, for example, operator 2) configured for the resource management contract 2 (i.e., resource management contract k, where the resource management contract k can be the above-mentioned resource management contract Con2). In this way, after the resource service device obtains the signature authorization instruction returned by the operation terminal corresponding to operator 2 (i.e., the above-mentioned operation terminal k), it can use the operation private key of operator 2 (i.e., the above-mentioned second operation private key) to sign the transaction T2' to be signed, and then the transaction signature information obtained by the transaction signature and the transaction T2' to be signed can be constructed. Figure 11 The signature transaction TX2 (i.e., the second signature transaction) corresponding to the operation service component 2 (i.e., the above-mentioned service component k) can be submitted to another blockchain (i.e., Figure 11 The target chain shown, for example, the target chain here is essentially a blockchain, and the target chain can specifically include the consensus node (i.e. Figure 11 The target consensus node shown, for example, the target consensus node here can specifically be the second consensus node mentioned above). The second consensus node is Figure 11 The specific process of contract verification (i.e. the above transaction verification) from steps (1) to (4) shown above can also be referred to the above Figure 9 The description of the specific process of transaction verification by the first consensus node in the corresponding embodiment before executing the modification business event will not be repeated here.

[0213] Similarly, if Figure 11 As shown, the specific implementation of the operation service component 3 in the resource service device to construct the signature transaction TX3 and the operation service component 4 to construct the signature transaction TX4 can also be referred to the above Figure 9The specific process of transaction verification by the first consensus node in the corresponding embodiment before executing the modification business event will not be described here. Figure 11 Among the four signature transactions shown, the signature content and approval signature lists carried in signature transaction TX1, signature transaction TX2, signature transaction TX3 and signature transaction TX4 are the same. The difference is that the Merkle path in signature transaction TX1 is a path from the tree node where the contract address D1 is located to the root node where the Merkle tree root is located (for example, Path1); the Merkle path in signature transaction TX2 is another path from the tree node where the contract address D2 is located to the root node where the Merkle tree root is located (for example, Path2); the Merkle path in signature transaction TX3 is another path from the tree node where the contract address D3 is located to the root node where the Merkle tree root is located (for example, Path3); and the Merkle path in signature transaction TX4 is another path from the tree node where the contract address D4 is located to the root node where the Merkle tree root is located (for example, Path4).

[0214] It can be seen that the resource service device involved in the embodiment of the present application can be used in the space-level signature scheme designed based on the Merkle tree root and Merkle path Merkle proof method through the signature management module (for example, Figure 11 The signature management module 110b) shown in the figure does not need to directly specify each contract address in the process of constructing the signature content to be signed. Instead, it improves and optimizes the signing experience of each approval object by providing the Merkle root associated with these contract addresses. It should be understood that in the embodiment of the present application, it is also possible to perform contract verification by providing the Merkle path of a specified contract address in the process of constructing the transaction content to be signed. It can be seen that the embodiment of the present application can provide a Merkle root and Merkle path method to replace the specific data structure of the original signature content and transaction content. In this way, in the process of contract verification through the Merkle root and Merkle path, it can be quickly proved that the resource management contract corresponding to the specified contract address is one of the resource management contracts corresponding to the corresponding contract address in the Merkle root.

[0215] Among them, it should be noted that in the embodiment of the present application, the approver only approves the Merkle root (i.e., MerkleRoot) in the signature content, and the operation service component only needs to add the Merkle path (i.e., Merkle Path) of a certain contract address on the basis of the signature content after the approval signature when constructing the signature transaction that needs to be on the chain, so as to facilitate the subsequent contract verification of the resource management contract on the corresponding consensus node. Among them, it can be understood that in the embodiment of the present application, the path length of the Merkle path (i.e., Merkle Path) of any contract address is the node where log2(N) hash values (i.e., Hash) are located (here N is the number of contract addresses selected in the business space).

[0216] In addition, it can be understood that when constructing the above-mentioned Merkle tree (i.e., Merkle tree), the embodiment of the present application uses the hash value (i.e., Hash) of each contract address as the node of the Merkle tree. In this way, it can be ensured that in the subsequent process of constructing the transaction content to be signed, the Merkle path (i.e., MerklePath) of the corresponding contract address can be attached to the transaction content, without directly carrying the contract address of other resource management contracts, thereby ensuring that the signed transaction signed by the private key of the corresponding operator does not directly expose the contract address of other resource management contracts. It should be understood that for other contract addresses that are not selected in the above-mentioned business space, they are essentially contract addresses in the Merkle tree that are not currently constructed. This means that the operation service components corresponding to other unselected contract addresses cannot be directly reused in the signatures in the approval signature list. In addition, the Merkle root involved in the embodiment of the present application can also be constructed in a timely and flexible manner, which means that the embodiment of the present application can flexibly construct a corresponding Merkle tree for some or all of the contract addresses selected from the current business space, thereby improving the flexibility of determining the Merkle root. Finally, in the embodiment of the present application, the hash value (i.e., Hash) on the leaf node in the Merkle tree is obtained by concatenating and hashing the contract address and the chain ID (i.e., chain identifier) of the blockchain where the resource management contract corresponding to the contract address is located. This means that the embodiment of the present application clarifies the contract address of a specific chain, and different chain IDs can be used to distinguish the resource management contracts deployed on each blockchain. In this way, when the contract address selected in the business space corresponds to a resource management contract on different chains, cross-chain address management applicable to multiple contract addresses under the business space can be quickly implemented through a single space signature.

[0217] Step S205: Obtain modification success event information from the resource management contract i running on the first consensus node;

[0218] Step S206: Based on the approval management relationship in the modification success event information, generate modification prompt information to indicate that the business approval object has been used as the approval object associated with contract address i. Based on the modification prompt information and the approval terminal corresponding to the third approval address, update the M approval terminals associated with the business space to obtain K approval terminals associated with the business space, where K is a positive integer greater than M.

[0219] The blockchain includes a first blockchain, the asset management contract i corresponding to the contract address i is an asset transfer contract for performing asset transfer on the first blockchain, and the consensus node on the first blockchain is a first consensus node;

[0220] Among them, it can be understood that in the embodiment of the present application, when the modification action indicated by the modification business event is to add an action to the approval object, that is, when the above-mentioned approver adds an operation, the first consensus node can call the corresponding resource management contract (for example, the above-mentioned resource management contract i) in the process of executing the modification business event to determine that the approval address (that is, the above-mentioned third approval address) of the newly added approver (that is, the business approval object) in the approval address addition parameter is registered and written to the target chain (for example, the above-mentioned first blockchain).

[0221] Optionally, at the same time, the second consensus node may also call the corresponding resource management contract (for example, the above-mentioned resource management contract k) in the process of executing the business event modification to determine that the approval address (that is, the above-mentioned third approval address) of the newly added approver (that is, the business approval object) in the approval address addition parameter is registered and written to the target chain (for example, the above-mentioned second blockchain).

[0222] It should be understood that after the first consensus node successfully registers and writes the third approval address of the business approval object into the resource management contract i, the resource service device can accept the modification success event information returned by the first consensus node to add a new approver for the above-mentioned contract address i. In this way, the resource service device can generate a modification prompt information based on the modification success event information to indicate that the business approval object has been used as the approval object for centralized management of the contract address i, and then based on the modification prompt information, the M approval terminals associated with the business space can be updated to obtain K approval terminals associated with the business space. In this way, when other business objects need to perform operations on a certain contract address in the business space (for example, the above-mentioned resource transfer operation), the following steps S207-S210 can be further executed.

[0223] Step S207: Receive an asset transfer event corresponding to the asset transfer operation triggered by the first business object for the asset transfer contract, and generate an asset transfer request for the asset transfer contract based on the resource transfer event; the second signature carried in the asset transfer request includes the contract address i and the asset transfer event. The asset transfer event is used to instruct the first business object to transfer the virtual assets in the asset transfer contract to the second business object;

[0224] Step S208: Send the asset transfer request to K approval terminals, so that the K approval terminals perform approval signatures on the second signature content to obtain approval signature information for the second signature content;

[0225] Step S209: Acquire the approval signature information returned by the K approval terminals, and construct a second approval signature list associated with the K approval terminals based on the acquired approval signature information;

[0226] In step S210, when the asset transfer signature transaction is constructed based on the first operation private key, the second signature content and the second approval signature list, the asset transfer signature transaction is sent to the first consensus node; the first consensus node is used to sign and verify the asset transfer signature transaction using the first operation public key corresponding to the first operation private key, and when the signature verification is successful, the asset transfer signature transaction is verified through the asset transfer contract, and when the transaction verification is successful, the asset transfer contract is called to execute the asset transfer event; the transaction verification includes address verification of the contract address i and multi-signature verification of the second approval signature list.

[0227] It can be seen from this that in the process of address management of different contract addresses in a certain space, the embodiment of the present application can select N contract addresses from the V contract addresses recorded in the business space based on the spatial concept of the business space and perform centralized modification operations. For example, the management terminal corresponding to the management object can generate a management request for sending to the resource service device based on the modification business event corresponding to this centralized modification operation triggered for these N contract addresses. In other words, the resource service device can flexibly configure the space operation serial number corresponding to this centralized modification operation based on the management request sent by the management terminal (for example, any one of the first management request or the second management request mentioned above), and then can form the signature content to be signed (that is, the first signature content mentioned above) on the resource service device side based on the Merkle tree root associated with these N contract addresses (for example, any one of the first Merkle tree root or the second Merkle tree root mentioned above), the space operation serial number, the modification timestamp corresponding to the modification business event, and the modification business event, so that the space management request carrying the signature content to be signed can be distributed to the approval terminals in the different approval groups associated with the business space. In this way, for any approval terminal in these different approval groups (that is, each approval terminal in the above M approval terminals), it is only necessary to perform an approval signature once for different contract addresses in the same business space, and it is possible to quickly obtain the approval signatures of these approvers (that is, the approval objects) for the same contract. The approval signature information of the signature content can be effectively improved in this way, not only in the approval signature stage, but also in the efficiency of the resource service device in address management of different contract addresses can be improved from the root. That is, after collecting the approval signature information of these approval objects, the resource service device can obtain the approval signature information from these approval signature information to construct an approval signature list that can be used for multi-signature verification (for example, the above-mentioned first approval signature list can include the approval signature information returned by the approval objects in different approval groups received). After that, based on the above-mentioned first signature content, the first approval signature list and the Merkle path of a certain contract address (for example, the above-mentioned contract address i), and the operation private key of the operation object i configured for the resource management contract i corresponding to the contract address i, a signature transaction (that is, the first signature transaction) is constructed to be sent to the consensus node (that is, the above-mentioned first consensus node) running the resource management contract i. In this way, after the first consensus node verifies the first signature transaction, it can execute the modification action indicated by the above-mentioned modification business event through the resource management contract i corresponding to the contract address (i.e., contract address i). For example, the approval address of a certain approver can be added to these N contract addresses in a centralized manner, so that different approvers can collaborate to achieve centralized management of different contract addresses in the same business space through the added approvers.In addition, in the embodiment of the present application, when the above-mentioned contract address i is an asset transfer contract for executing an asset transfer operation on the first blockchain, it is possible to receive an asset transfer event corresponding to an asset transfer operation triggered by a certain business object (i.e., the first business object) through the asset transfer contract, and then generate an asset transfer request for the contract address (i.e., contract address i) of the single asset transfer contract based on the asset transfer event. For example, the signature content (i.e., the second signature content) carried in the asset transfer request here can specifically include the contract address i and the asset transfer event, and then the second signature content can be approved and signed by L approval terminals corresponding to the L approval objects with newly added approvers. It should be noted that in the embodiment of the present application, the second signature content carries a specific contract address (e.g., contract address i), which means that at this time, when the L approval terminals sign the approval signature for this asset transfer operation, they sign the contract address i in the second signature content. It can be seen from this that the embodiment of the application itself can ensure the reliability of the asset transfer contract used for asset transfer by separately managing the space management service in the address management process corresponding to the above-mentioned centralized modification operation and the asset management service in the asset transfer process corresponding to the asset transfer operation here. In the asset transfer process, the address verification of the contract address i and the multi-signature verification of the approval signature information in the second approval signature list can be performed. It can also ensure the security of the virtual asset transfer.

[0228] For further information, see Figure 12 , Figure 12 This is a data processing method based on blockchain provided by an embodiment of the present application. The method is executed by the first consensus node, which can be the above-mentioned Figure 2 The target consensus node in the corresponding embodiment. Wherein, when the target consensus node is the first consensus node, the first consensus node can be the consensus node on the blockchain associated with the contract address i, the contract address i is included in N contract addresses, the N contract addresses are deployed in the business space of the resource business service system, N is a positive integer greater than 1, the operation object corresponding to the contract address i is the operation object i, the resource management contract corresponding to the contract address i is the resource management contract i on the blockchain, and i is a positive integer less than or equal to N. Figure 12 As shown, the method may at least include steps S301 to S304.

[0229] Step S301, receiving a first signature transaction sent by a resource service device in a resource business service system; the first signature transaction is constructed by the resource service device based on the first operation private key, the first signature content, the first Merkle path, and the first approval signature list of the operation object i; the first signature content is determined by the resource service device based on the acquired space management request associated with N contract addresses, and the first signature content includes the Merkle tree root associated with the N contract addresses and the modification business event triggered for the N contract addresses; the first Merkle path refers to the path from the contract address i to the Merkle tree root; the space management request is used to instruct the M approval terminals associated with the business space to approve and sign the first signature content, and obtain the approval signature information for the first signature content; the first approval signature list is constructed by the resource service device based on the approval signature information returned by the M approval terminals;

[0230] Step S302: Verify the first signed transaction using the first operation public key corresponding to the first operation private key to obtain a transaction verification result.

[0231] Step S303: When the transaction verification result indicates that the transaction verification is successful, the resource management contract i is used to perform transaction verification on the first signed transaction to obtain a transaction verification result.

[0232] The transaction verification includes root verification of the Merkle tree root based on the first Merkle path and multi-signature verification of the first approval signature list;

[0233] Wherein, the blockchain includes a first blockchain, and the blockchain where the resource management contract i is located is the first blockchain. At this time, the first consensus node can be specifically used to perform the following steps: the first consensus node can determine the chain identifier of the first blockchain as the first chain identifier through the resource management contract i, and perform a first splicing process on the first chain identifier and the contract address i to obtain the first splicing processing information associated with the contract address i; further, the first consensus node can perform a hash value calculation on the first splicing processing information to obtain the first hash calculation value of the first splicing processing information, and can determine the tree node associated with the contract address i based on the first Merkel path. The associated verification node uses the hash value on the associated verification node as the first associated hash value, reconstructs the Merkle tree root to be compared based on the first hash calculation value and the first associated hash value, and can perform root verification on the Merkle tree root to be compared to obtain a root verification result; further, the first consensus node can restore the approval signature information associated with the M approval terminals from the first approval signature list included in the transaction content of the first signed transaction, and can count the number of signatures associated with the restored approval signature information, perform multi-signature verification on the first approval signature list based on the signature statistics, and obtain a multi-signature verification result;

[0234] It should be understood that the number of signature statistics here includes but is not limited to the number of approval groups in which the approval object (i.e., approver) corresponding to the approval signature information obtained by statistical restoration is located, and the number of signatures of the approval information in each of these approval groups. Furthermore, the first consensus node can determine the transaction verification result based on the root verification result and the multi-signature verification result.

[0235] Among them, there are M approval objects corresponding to M approval terminals, one approval object belongs to one approval group, and one approval group includes at least one approval object; the root verification result includes a root verification success result for indicating that the Merkle tree root to be compared is consistent with the Merkle tree root; the multi-signature verification result includes a multi-signature verification success result for indicating that the statistical number of signatures reaches the multi-signature signature threshold indicated by the multi-signature verification; the statistical number of signatures is determined by the number of groups in the approval group to which the approval objects participating in the approval signature belong; at this time, the first consensus node can use the root verification success result and the multi-signature verification success result as the transaction verification success result corresponding to the first signature transaction when the root verification result includes the root verification success result and the multi-signature verification result includes the multi-signature verification success result, so that the transaction verification result can be determined based on the transaction verification success result.

[0236] Optionally, the blockchain includes a first blockchain, on which N resource management contracts corresponding to N contract addresses are deployed, one contract address corresponds to one resource management contract, the N contract addresses include a contract address j, the resource management contract corresponding to the contract address j is the resource management contract j, j is a positive integer less than or equal to N, and j is not equal to i; the operation object corresponding to the contract address j is the operation object j, the first signature transaction is a transaction among the multiple signature transactions contained in the target block, and the target block is a block to be uploaded to the first blockchain; it can be understood that at this time, the first consensus node can also receive a third signature transaction sent by the resource service device and signed by the operation object j (that is, another first signature transaction, the other first signature transaction can specifically be the above-mentioned signature transaction TX4, that is, the signature transaction TX4 can be constructed by the operation service component 4 corresponding to the above-mentioned contract address D4); in other words, the third signature transaction here is the resource service device after determining the third signature transaction signed by the operation object j. When the contract address j points to the third Merkle path of the Merkle tree root, it is constructed based on the third operation private key of the operation object j, the first signature content, the second Merkle path and the first approval signature list; further, the first consensus node can add the first signature transaction and the third signature transaction to the transaction pool of the first consensus node, and then when the transaction pool meets the transaction packaging conditions, it can obtain multiple signature transactions including the first signature transaction and the third signature transaction from the transaction pool to package the multiple signature transactions here into the target block; in this way, the first consensus node can further perform block consensus on the target block to obtain a block consensus result; it can be understood that the block consensus here can specifically include calling the resource management contract i to execute the modification business event and calling the resource management contract j to execute the modification business event; further, the first consensus node can, when the block consensus result indicates that the target block has reached a block consensus, chain the target block that has reached the block consensus to the first blockchain.

[0237] Step S304: When the transaction verification result indicates that the transaction verification is successful, the resource management contract i is called to execute the modification business event.

[0238] It can be seen from this that in the embodiment of the present application, if there is a resource management contract deployed on the same target chain among the N resource management contracts corresponding to the N contract addresses (for example, the above Figure 7The resource management contract Con1 and resource management contract Con4 shown in the figure), for example, the target chain (i.e., blockchain) here can specifically include any one of the first blockchain or the second blockchain mentioned above. For ease of understanding, let's take the target chain including the first blockchain as an example. At this time, the first consensus node on the first blockchain can receive the signature transaction (e.g., the first signature transaction and the third signature transaction) signed by the resource service device through the resource service components corresponding to different contract addresses (e.g., the resource service component 1 and the resource service component 4 mentioned above), and then after performing transaction verification and transaction verification on the received signature transactions, it can be determined that these received signature transactions have transaction legitimacy, so that the received signature transactions with legitimacy can be packaged together into the same block, and then when performing block consensus on the same block (i.e., the target block), the modification business events in these signature transactions in the target block can be traversed and executed. It can be seen that the embodiment of the present application introduces the modification business events related to these contract addresses in the process of constructing the signature content. The associated Merkle tree root can effectively improve the efficiency of different approval objects in approving and signing the same signature content. In this way, the first consensus node can receive the signature transactions with Merkle paths of different contract addresses submitted by the resource service device through different resource service components as quickly as possible. In this way, in the process of contract verification (i.e., the above-mentioned transaction verification), without introducing the contract addresses of other resource management contracts, it is possible to directly determine through the Merkle tree root and the Merkle path of the corresponding contract address that the corresponding resource management contract currently running on the first consensus node is the contract address in the business space corresponding to the Merkle tree root where this contract address is located. Then, while quickly determining the legitimacy of multiple different signature transactions submitted by the resource service device, the transaction chain security and reliability of different signature transactions can be achieved.

[0239] For further information, see Figure 13 , Figure 13 This is an interactive sequence diagram of a data processing method based on blockchain provided by an embodiment of the present application. The method is interactively executed by a resource service device in a resource business service system, a target approval terminal among M approval terminals, and a first consensus node running a resource management contract i. The business space of the resource business service system includes N contract addresses, where N is a positive integer greater than 1, and the N contract addresses include a contract address i. The operation object corresponding to the contract address i is the operation object i, and the resource management contract corresponding to the contract address i is the resource management contract i on the blockchain, where i is a positive integer less than or equal to N. Figure 13 As shown, the method may at least include steps S501 to S509.

[0240] Step S501: The resource service device may obtain a space management request associated with N contract addresses;

[0241] The first signature carried in the space management request includes the Merkle tree root associated with N contract addresses and the modification business event triggered for the N contract addresses;

[0242] Step S502: The resource service device may send a space management request to a target approval terminal among the M approval terminals associated with the business space;

[0243] It can be understood that the target approval terminal here can be any one of the M approval terminals.

[0244] Step S503: The target approval terminal may perform approval signature on the first signature content to obtain approval signature information for the first signature content; M is a positive integer greater than 1;

[0245] It is understandable that the first signature content here may specifically be the signature content to be signed that carries the Merkle tree root and is sent by the resource service device.

[0246] It is understood that, in the embodiment of the present application, the specific process of adding approvers for different contract addresses in the business space may include the following steps:

[0247] (1) Initiate approval: For example, the resource service device can initiate an approval signature for the signature content (i.e., the first signature content): It can be understood that in the embodiment of the present application, the resource service device can calculate the Merkle root (i.e., the above-mentioned Merkle Root, abbreviated as Root) of all contract addresses in the N contract addresses selected in the current business space based on the N contract addresses selected in the business space. For example, assuming there are 4 contract addresses, then in the management terminal Figure 13 When the target approval terminal is shown, the management object corresponding to the management terminal is based on the concept of space. The operation target of the centralized modification operation for different contract addresses in the space can be to add an approver for each of the four contract addresses.

[0248] (2) Approver’s signature: For example, each of the M approval terminals involved in the embodiment of the present application may correspond to an approval object (i.e., an approver), and each of these approvers may sign the content parameters in the following signature content (e.g., the first signature content) (i.e., the above-mentioned approval signature):

[0249] The modification action in the modification business event may be: adding an action to the approval object (ie, AddOwner), for example, the above-mentioned approver adding operation.

[0250] The modified parameter in the business modification event may be: an approval address parameter is added. The approval address parameter here may specifically be the approval address of the newly added approver (i.e., the business approval object, e.g., the new Owner): 0x4cd1413b7ac8B7B9d5afcAe0Feeb07926dc06027. The approval address of the new Owner may be the third approval address.

[0251] It can be understood that if there is a target contract address among N contract addresses, for ease of understanding, here we take the target contract address as the above-mentioned contract address i as an example. In this case, contract address i can be: 0xce62aE7b4EDe7F8Bf3c97394e6021ef51eC5246D. At this time, in the first signature content, the Merkle root obtained by performing Merkle root calculation on these N contract addresses can be: 06A9215327fE087Dfd6cA29e2D1b8C729d0f7C5A (MerkleRoot).

[0252] The management nonce (the spatial operation sequence number configured or managed for this centralized modification operation) is understood to be greater than the contract operation sequence number of each current resource management contract. (It should be understood that in this embodiment of the application, the nonce variable used to represent the spatial operation sequence number is centrally managed and configured by the resource service device.)

[0253] Other parameters: such as modification operation timestamp, approval signature timestamp, etc., among which the modification operation timestamp refers to the trigger timestamp of the above-mentioned centralized modification operation. The modification operation timestamp here will be recorded in the multi-signature transaction returned by these approval terminals in the form of transactions during the multi-signature process. An approval terminal can return multiple multi-signature transactions for the current first signature content. A multi-signature transaction can carry the approval signature information carried by an approval object to approve the signature content (for example, the first signature content).

[0254] For further understanding, please see Figure 14 , Figure 14 This is a schematic diagram of a scenario for submitting a multi-signature transaction provided by an embodiment of this application. For ease of understanding, the M approval objects corresponding to M approval terminals are used as Figure 14Take approver A, approver B, and approver C as an example, where approver A can submit an approval signature transaction U01 to the transaction collection component in the resource service device through the approval terminal, and approver B can submit an approval signature transaction U02 to the transaction collection component in the resource service device through the approval terminal. Similarly, approver C can submit an approval signature transaction U03 to the transaction collection component in the resource service device through the approval terminal. The transaction collection component here can be used to collect a multi-signature transaction submitted by each approval terminal in the multi-signature process of M approval terminals. For example, the multi-signature transaction here can specifically include Figure 14 The approval signature transaction U01, approval signature transaction U02 and approval signature transaction U03 are shown. It can be understood that the transaction collection component here can be used to collect the transaction information of each approver (for example, Figure 11 The approval signature transaction obtained by the approver A, approver B and approver C) for the same signature content (the transaction parameters in the approval transaction here can specifically include the first signature content and the approval signature information obtained by the approval signature for the first signature content). The transaction collection component is deployed on the above Figure 11 Components in the signature management module 110b in the corresponding embodiment.

[0255] like Figure 14 As shown, after collecting the approval signature transactions submitted by each approver, the resource service device can construct an approval signature list associated with the approval signature information in these approval signature transactions. It should be understood that in the embodiment of the present application, the approval signature list can directly carry the approval signature information of these approval signature transactions or can also directly carry these approval signature transactions.

[0256] like Figure 14 As shown, the operation service component of the resource service device can be used to package these approval signature transactions to integrate the signature transactions carrying these approval signature transactions. It can be understood that when the operation service component is the above-mentioned operation service component 1, the signature transaction here can specifically be the signature transaction TX1 constructed by the above-mentioned operation service component 1 based on the Merkle path of the first signature content, the first approval signature list and the contract address D1. In this way, the resource service device can write the integrated signature transaction (for example, signature transaction TX1) into the chain in the form of a transaction. Figure 14 The target chain shown (e.g., the first blockchain described above).

[0257] (3) Constructing and signing a transaction through a Relayer (i.e., the operation service component corresponding to the operator): It is understandable that, in the embodiment of the present application, each of the N resource management contracts corresponding to the N contract addresses corresponds to a Relayer (i.e., the operation service component corresponding to the operator). In the embodiment of the present application, the resource service device can obtain the signature of a certain operator (i.e., the transaction signature information) and fill the operator's signature into the transaction parameters of the following transaction content to construct a signed transaction that can be written to the corresponding blockchain:

[0258] All parameters in the signed transaction content above;

[0259] The Merkle path of the contract address i;

[0260] The signature itself obtained by signing the transaction using the operator’s private key.

[0261] (4) Relayer submits to the chain. In the embodiment of the present application, the resource service device can write the signed transaction constructed by the operation service component i to the corresponding blockchain (for example, the above-mentioned first blockchain) through the operation service component corresponding to the corresponding operator (for example, the above-mentioned operation service component i).

[0262] Step S504: The target approval terminal returns approval signature information to the resource service device.

[0263] It is understood that the resource service device can receive the approval signature information returned by the target approval terminal in the form of a transaction, and the transaction in which the approval signature information is included can be the above-mentioned approval signature transaction. In addition, the resource service device here can also receive the approval signature information returned by other approval terminals in the form of transactions in the M approval terminals.

[0264] In step S505, the resource service device may obtain the approval signature information returned by the M approval terminals. Based on the obtained approval signature information, the resource service device constructs a first approval signature list associated with the M approval terminals and determines the first Merkle path from the contract address i to the Merkle tree root.

[0265] In step S506, the resource service device may obtain the first operation private key of the operation object i, and construct a first signed transaction based on the first operation private key, the first signature content, the first Merkle path, and the first approval signature list, and then send the first signed transaction to the first consensus node running the resource management contract i.

[0266] It should be understood that when the resource service device sends the constructed first signature transaction to the first consensus node, the first consensus node can receive the first signature transaction sent by the resource service device while maintaining a long connection with the resource service device, so as to further perform the following step S505;

[0267] In step S507, the first consensus node may verify the first signed transaction using the first operation public key corresponding to the first operation private key to obtain a transaction verification result.

[0268] In step S508, when the transaction verification result indicates that the transaction verification is successful, the first consensus node may verify the first signed transaction through the resource management contract i to obtain a transaction verification result; the transaction verification includes performing root verification on the Merkle tree root based on the first Merkle path and performing multi-signature verification on the first approval signature list;

[0269] Step S509: When the transaction verification result indicates that the transaction verification is successful, the resource management contract i is called to execute the modification business event.

[0270] Thus, in the embodiment of the present application, the resource service device can receive the approval signature transaction submitted by each of the M approval terminals in the form of a transaction. The approval signature transaction here can carry the above-mentioned first signature content and the approval signature information obtained by the approval object approving the first signature content. After collecting these approval signature transactions carrying approval signature information, the resource service device can write these approval signature transactions into the above-mentioned first approval signature list, and then construct a signature transaction for submission to the first consensus node based on the first signature content, the first approval signature list and the transaction signature information of a certain operation object (for example, the above-mentioned operation object i). In this way, the first consensus node verifies the first signature transaction using the first operation public key corresponding to the first operation private key, and when the transaction verification is successful, it can obtain the above-mentioned first signature content and the first approval signature list carrying different approval signature transactions. Furthermore, the resource service device can perform transaction verification on the first signature transaction through the resource management contract i, and when the transaction verification is successful, it can call the resource management contract i to execute the modification business event; the transaction verification here includes root verification of the Merkle tree root based on the first Merkle path and multi-signature verification of the first approval signature list. Among them, it can be understood that the embodiment of the present application can restore the approval signature information in different approval signature transactions based on the transaction parameters of different approval signature transactions, and then perform multi-signature verification on these restored approval signature information. In this way, the first consensus node can call the resource management contract i to perform the modification action indicated by the modification business event (for example, the above-mentioned approval object addition action for adding a new approver) when the root verification is successful and the multi-signature verification is successful. Then, the root verification and multi-signature verification and other transaction verification methods can be used to ensure the security and reliability of the first signature transaction written to the target chain (for example, the first blockchain). In addition, it should be understood that the embodiment of the present application can package the collected multiple approval signature transactions into a signature transaction by each approval terminal in the M approval terminals performing approval signatures off-chain. It can achieve the simultaneous chaining of multiple approval signature transactions in the signature transaction while the signature transaction is being chained. In this way, the phenomenon of directly submitting the approval signature transaction to the first consensus node can be avoided, thereby reducing the transaction chaining cost when the transaction is chained.

[0271] For further information, see Figure 15 , Figure 15 This is a structural diagram of a blockchain-based data processing device provided in an embodiment of the present application. The blockchain-based data processing device 1 can be a computer program (including program code) running on a computer device. For example, the blockchain-based data processing device 1 is an application software. The blockchain-based data processing device 1 can be used to execute the corresponding steps of the method provided in the embodiment of the present application. Figure 15 As shown, the blockchain-based data processing device 1 may include: a management request acquisition module 11, a management request sending module 12, a signature list construction module 13, and a signature transaction sending module 14;

[0272] A management request acquisition module 11 is configured to acquire space management requests associated with N contract addresses. The first signature carried in the space management request includes the Merkle tree root associated with the N contract addresses and the modification business event triggered for the N contract addresses.

[0273] A management request sending module 12 is configured to send a space management request to M approval terminals associated with the business space, so that the M approval terminals perform approval signatures on the first signature content to obtain approval signature information for the first signature content; M is a positive integer greater than 1;

[0274] The signature list construction module 13 is used to obtain the approval signature information returned by the M approval terminals, and based on the obtained approval signature information, construct a first approval signature list associated with the M approval terminals, and determine the first Merkle path from the contract address i to the Merkle tree root;

[0275] The signature transaction sending module 14 is used to obtain the first operation private key of the operation object i, and when the first signature transaction is constructed based on the first operation private key, the first signature content, the first Merkle path and the first approval signature list, the first signature transaction is sent to the first consensus node running the resource management contract i; the first consensus node is used to verify the first signature transaction through the first operation public key corresponding to the first operation private key, and when the transaction verification is successful, the first signature transaction is verified through the resource management contract i, and when the transaction verification is successful, the resource management contract i is called to execute the modification business event; the transaction verification includes root verification of the Merkle tree root based on the first Merkle path and multi-signature verification of the first approval signature list.

[0276] The specific implementation of the management request acquisition module 11, the management request sending module 12, the signature list construction module 13, and the signature transaction sending module 14 can be found in the above Figure 3 The description of steps S101 to S104 in the corresponding embodiment will not be repeated here.

[0277] The management terminal associated with the M approval terminals is the first management terminal; each of the M approval terminals is a terminal added by the first management terminal for the approval signature of N contract addresses.

[0278] The management request acquisition module 11 includes: an access request receiving unit 111, a service page returning unit 112, a management request receiving unit 113, an operation sequence number configuring unit 114 and a management request determining unit 115;

[0279] The access request receiving unit 111 is configured to receive a system access request submitted by a first management terminal, and perform identity authentication on the management object corresponding to the first management terminal based on the object access information carried in the system access request to obtain an identity authentication result;

[0280] The service page returning unit 112 is configured to return a business service page provided by the resource business service system to the first management terminal if the identity authentication result indicates that the management object has access rights to the resource business service system;

[0281] The management request receiving unit 113 is configured to receive a first management request sent by the first management terminal; the first management request is generated by the first management terminal in response to a centralized modification operation performed on N contract addresses on the business service page, based on a modification business event corresponding to the centralized modification operation;

[0282] An operation sequence number configuration unit 114 is configured to configure a spatial operation sequence number corresponding to the centralized modification operation based on the first management request;

[0283] The management request determination unit 115 is used to obtain the Merkle tree root associated with N contract addresses, and use the Merkle tree root, the space operation sequence number, the modification timestamp corresponding to the modified business event, and the modified business event as the first signature content to be signed, and determine the space management request associated with the N contract addresses based on the first signature content.

[0284] Among them, the specific implementation methods of the access request receiving unit 111, the service page returning unit 112, the management request receiving unit 113, the operation sequence number configuration unit 114 and the management request determination unit 115 can be found in the description of the specific process of the management object sending a space management request through the first management terminal in the embodiment of the present application, and will not be further elaborated here.

[0285] Among them, N contract addresses correspond to N resource management contracts;

[0286] The operation sequence number configuration unit 114 is specifically configured to obtain the contract operation sequence number of each resource management contract in the N resource management contracts based on the first management request;

[0287] The operation number configuration unit 114 is further specifically configured to select a maximum contract operation number from the contract operation numbers of each resource management contract, and increment the selected maximum contract operation number to obtain the incremented maximum contract operation number;

[0288] The operation sequence number configuration unit 114 is further specifically configured to determine the incremented maximum contract operation sequence number as the space operation sequence number corresponding to the centralized modification operation.

[0289] The N contract addresses are selected by the management object from a business service page provided by the business service system, the blockchain includes a first blockchain on which N resource management contracts corresponding to the N contract addresses are deployed, and the chain identifier of the first blockchain is a first chain identifier; the Merkle tree root includes a first Merkle tree root associated with the N contract addresses;

[0290] The device 1 further includes: a splicing processing module 15, a hash transformation module 16 and a Merkle tree root determination module 17;

[0291] The splicing processing module 15 is used to splice the first chain identifier and each of the N contract addresses to obtain address splicing information of each contract address; the address splicing information of a contract address is obtained by splicing the first chain identifier and a contract address;

[0292] Hash transformation module 16 is used to perform hash transformation on the address splicing information of each contract address to obtain the address hash value corresponding to the address splicing information of each contract address; the address splicing information of one contract address corresponds to one address hash value;

[0293] The Merkle tree root determination module 17 is used to use the address hash value corresponding to the address splicing information of each contract address as the leaf node of the first Merkle tree, construct the first Merkle tree based on the leaf nodes of the first Merkle tree, and use the root node of the first Merkle tree as the first Merkle tree root associated with N contract addresses.

[0294] It is understood that when the N contract addresses are contract addresses of different resource management contracts on the same blockchain, the specific implementation of the splicing processing module 15, the hash transformation module 16 and the Merkle tree root determination module 17 can be found in the above Figure 6 The description of the specific process of constructing the first Merkle tree root through N contract addresses on the same blockchain in the corresponding embodiment will not be repeated here.

[0295] Wherein, the N contract addresses include N1 first contract addresses and N2 second contract addresses; N=N1+N2, N1 and N2 are both positive integers, the blockchain includes a first blockchain on which N1 resource management contracts corresponding to the N1 first contract addresses are deployed and a second blockchain on which N2 resource management contracts corresponding to the N2 second contract addresses are deployed, the chain identifier of the first blockchain is the first chain identifier, the chain identifier of the second blockchain is the second chain identifier, and the Merkle tree root includes a second Merkle tree root associated with the N1 first contract addresses and the N2 second contract addresses;

[0296] The splicing processing module 15 is further configured to use each of the N1 first contract addresses as the first chain contract address, and to perform splicing processing on the first chain identifier and the first chain contract address to obtain first address splicing information of the first chain contract address;

[0297] The splicing processing module 15 is further configured to use each of the N2 second contract addresses as the second chain contract address, and to perform splicing processing on the second chain identifier and the second chain contract address to obtain second address splicing information of the second chain contract address;

[0298] The hash transformation module 16 is further configured to perform a hash transformation on the first address splicing information to obtain a first address hash value corresponding to the first address splicing information, and perform a hash transformation on the second address splicing information to obtain a second address hash value corresponding to the second address splicing information;

[0299] The Merkle tree root determination module 17 is further configured to use the first address hash value and the second address hash value as leaf nodes of the second Merkle tree, respectively, to construct a second Merkle tree based on the leaf nodes of the second Merkle tree, and to use the root node of the second Merkle tree as the second Merkle tree root associated with the N1 first contract addresses and the N2 second contract addresses.

[0300] It is understood that when the N contract addresses are contract addresses of different resource management contracts on different blockchains, the specific implementation of the splicing processing module 15, the hash transformation module 16 and the Merkle tree root determination module 17 can also be found in the above Figure 7 The description of the specific process of constructing the second Merkle tree root through N contract addresses on different blockchains in the corresponding embodiment will not be repeated here.

[0301] The management terminal associated with the M approval terminals is the second management terminal, and the second management terminal is the target approval terminal among the M approval terminals; the target approval terminal is the approval terminal among the M approval terminals that has access rights to the resource business service system;

[0302] The management request acquisition module 11 is further configured to receive a second management request sent by a target approval terminal; the second management request is generated by the target approval terminal in response to a centralized modification operation performed on N contract addresses on a business service page, based on a modification business event corresponding to the centralized modification operation; the business service page is provided by the approval subject corresponding to the target approval terminal when accessing the resource business service system based on access rights;

[0303] The management request acquisition module 11 is further configured to configure a spatial operation sequence number corresponding to the centralized modification operation based on the second management request;

[0304] The management request acquisition module 11 is also used to obtain the Merkle tree root associated with N contract addresses, and use the Merkle tree root, the space operation sequence number, the modification timestamp corresponding to the modified business event, and the modified business event as the first signature content to be signed, and determine the space management request associated with the N contract addresses based on the first signature content.

[0305] The blockchain includes a first blockchain; the M approval terminals include a first approval terminal and a second approval terminal; the approval address of the first approval terminal is the first approval address, and the approval address of the second approval terminal is the second approval address; the first approval address and the second approval address are both on-chain registered addresses after the address is registered on the first blockchain; the business modification event includes at least an approval object addition action and an approval address addition parameter; the approval object addition action refers to the centralized addition of a business approval object for approval signatures to N contract addresses, and the approval address addition parameter is a third approval address of the business approval object; the third approval address is the approval address to be registered on the first blockchain;

[0306] The signature list construction module 13 includes: a first signature information receiving unit 131, a second signature information receiving unit 132 and a signature information determining unit 133;

[0307] The first signature information receiving unit 131 is configured to receive the first approval signature information returned by the first approval terminal. The first approval signature information is obtained by the first approval terminal, when obtaining the first signature content based on the space management request, adding an action to the approval object in the first signature content, adding parameters to the approval address, and performing content approval on the Merkle tree root. When the content approval is completed, the first approval content is approved and signed using the first private key corresponding to the first approval address.

[0308] The second signature information receiving unit 132 is configured to receive the second approval signature information returned by the second approval terminal. The second approval signature information is obtained by the second approval terminal, when obtaining the first signature content based on the space management request, adding an action to the approval object in the first signature content, adding parameters to the approval address, and performing content approval on the Merkle tree root. When the content approval is completed, the second approval terminal uses the second private key corresponding to the second approval address to approve the first signature content. The second private key is different from the first private key.

[0309] The signature information determining unit 133 is configured to determine the approval signature information returned by each approval terminal based on the first approval signature information and the second approval signature information.

[0310] The specific implementation of the first signature information receiving unit 131, the second signature information receiving unit 132 and the signature information determining unit 133 can be found in the above Figure 3 The description of the specific process of obtaining the approval signature information fed back by the M approval terminals in the corresponding embodiment will not be repeated here.

[0311] In which, the blockchain includes a first blockchain; the approval address of each approval terminal in the M approval terminals is an on-chain registered address after the address is registered on the first blockchain, the M approval terminals include approval terminal m, m is a positive integer less than or equal to M, and the modification business event includes at least an approval object removal action and an approval address removal parameter; the approval object removal action refers to the centralized removal of the approval object corresponding to the approval terminal m used for approval signature for N contract addresses, and the approval address removal parameter is used to indicate the removal of the approval address of the approval object corresponding to the approval terminal m on the first blockchain.

[0312] The blockchain includes a first blockchain, a resource management contract i corresponding to a contract address i is deployed on the first blockchain, a consensus node on the first blockchain is a first consensus node, an operation service component corresponding to an operation object i is deployed in the resource service device, and an operation terminal corresponding to the operation object i is an operation terminal i;

[0313] The signature transaction sending module 14 includes: a component determination unit 141, a signature authorization unit 142, a transaction signing unit 143 and a first transaction sending unit 144;

[0314] Component determining unit 141 is configured to determine the operation service component corresponding to operation object i as operation service component i, use the first signature content, the first Merkle path, and the first approval signature list as the transaction content of a first transaction to be signed via operation service component i, and when the first transaction to be signed is constructed based on the transaction content, send a transaction signature request for the first transaction to be signed to operation terminal i; the transaction signature request is used to instruct operation terminal i to generate a signature authorization instruction corresponding to the signature authorization operation in response to the signature authorization operation on the first transaction to be signed;

[0315] The signature authorization unit 142 is configured to receive the signature authorization instruction returned by the operation terminal i, and obtain the first operation private key of the operation object i from the resource business service system based on the signature authorization instruction;

[0316] The transaction signing unit 143 is configured to sign the first transaction to be signed using the first operation private key of the operation object i to obtain transaction signature information for the first transaction to be signed;

[0317] The first transaction sending unit 144 is used to construct a first signed transaction corresponding to the operation service component i based on the first transaction to be signed and the transaction signature information, and send the first signed transaction to the first consensus node; the first consensus node is used to verify the first signed transaction through the first operation public key when the first operation public key corresponding to the first operation private key is obtained, and when the transaction verification is successful, the first signed transaction is verified through the resource management contract corresponding to the contract address i, and when the transaction verification is successful, the resource management contract corresponding to the contract address i is called to execute the modification business event.

[0318] The specific implementation of the component determination unit 141, the signature authorization unit 142, the transaction signature unit 143 and the first transaction sending unit 144 can be found in the above Figure 3 The description of the specific process of sending the first signature transaction to the first consensus node in the corresponding embodiment will not be repeated here.

[0319] The blockchain includes a second blockchain different from the first blockchain, the N contract addresses include a contract address k, where k is a positive integer less than or equal to N; the resource management contract corresponding to the contract address k is a resource management contract k, the resource management contract k is deployed on the second blockchain, the consensus node on the second blockchain is a second consensus node, and the operation object corresponding to the contract address k is an operation object k;

[0320] The signature transaction sending module 14 further includes: a second transaction sending unit 145;

[0321] The second transaction sending unit 145 is used to determine a second Merkle path from the contract address k to the Merkle tree root;

[0322] The second transaction sending unit 145 is further used to obtain the second operation private key of the operation object k, and when the second signature transaction is constructed based on the second operation private key, the first signature content, the second Merkle path and the first approval signature list, the second signature transaction is sent to the second consensus node; the second consensus node is used to verify the second signature transaction through the second operation public key corresponding to the second operation private key, and when the transaction verification is successful, the second signature transaction is verified through the resource management contract k, and when the transaction verification is successful, the resource management contract k is called to execute the modification business event; the transaction verification includes root verification of the Merkle tree root based on the second Merkle path and multi-signature verification of the first approval signature list.

[0323] The specific implementation of the second transaction sending unit 145 can be found in the above Figure 3 The description of the specific process of sending the second signature transaction to the second consensus node in the corresponding embodiment will not be repeated here.

[0324] Among them, the modification business event at least includes the action of adding an approval object and the parameter of adding an approval address; the action of adding an approval object refers to the centralized addition of a business approval object for approval signature for N contract addresses, and the parameter of adding the approval address is the third approval address of the business approval object; the third approval address is the approval address to be registered on the first blockchain; the first consensus node is used to add the approval management relationship between the business approval object and the contract address i when calling the resource management contract i to execute the modification business event, and when the first signature transaction carrying the third approval address is chained to the first blockchain based on the approval management relationship, the modification success event information carrying the approval management relationship is recorded through the resource management contract i;

[0325] The device 1 further includes: an event information acquisition module 18 and a prompt information generation module 19;

[0326] An event information acquisition module 18 is used to obtain modification success event information from the resource management contract i running on the first consensus node;

[0327] The prompt information generation module 19 is used to generate a modification prompt information indicating that the business approval object has been used as the approval object associated with the contract address i based on the approval management relationship in the modification success event information. Based on the modification prompt information and the approval terminal corresponding to the third approval address, the M approval terminals associated with the business space are updated to obtain K approval terminals associated with the business space, where K is a positive integer greater than M.

[0328] The specific implementation of the event information acquisition module 18 and the prompt information generation module 19 can be found in the above Figure 3The description of the specific implementation method of updating the service terminal in the service space in the corresponding embodiment will not be repeated here.

[0329] The blockchain includes a first blockchain, the asset management contract i corresponding to the contract address i is an asset transfer contract for performing asset transfer on the first blockchain, and the consensus node on the first blockchain is a first consensus node;

[0330] The apparatus 1 further comprises: a transfer request receiving module 20 and a transfer request sending module 21;

[0331] The transfer request receiving module 20 is configured to receive an asset transfer event corresponding to an asset transfer operation triggered by a first business object for an asset transfer contract, and generate an asset transfer request for the asset transfer contract based on the resource transfer event. The second signature carried in the asset transfer request includes the contract address i and the asset transfer event. The asset transfer event is used to instruct the first business object to transfer the virtual assets in the asset transfer contract to the second business object.

[0332] The transfer request sending module 21 is used to send the asset transfer request to K approval terminals, so that the K approval terminals can sign the second signature content and obtain approval signature information for the second signature content;

[0333] The signature list construction module 13 is used to obtain the approval signature information returned by the K approval terminals, and construct a second approval signature list associated with the K approval terminals based on the obtained approval signature information;

[0334] The signature transaction sending module 14 is used to send the asset transfer signature transaction to the first consensus node when the asset transfer signature transaction is constructed based on the first operation private key, the second signature content and the second approval signature list; the first consensus node is used to sign and verify the asset transfer signature transaction through the first operation public key corresponding to the first operation private key, and when the signature verification is successful, the asset transfer signature transaction is verified through the asset transfer contract, and when the transaction verification is successful, the asset transfer contract is called to execute the asset transfer event; the transaction verification includes address verification of the contract address i and multi-signature verification of the second approval signature list.

[0335] The specific implementation of the transfer request receiving module 20 and the transfer request sending module 21 can be found in the above Figure 10 The description of the specific process of sending the asset transfer signature transaction to the first consensus node in the corresponding embodiment will not be repeated here. In addition, for the blockchain-based data processing device, the description of the same beneficial effects obtained by sampling the same method will not be repeated here.

[0336] For further information, see Figure 16 , Figure 16 This is a structural diagram of a blockchain-based data processing device provided in an embodiment of the present application. The blockchain-based data processing device 2 can be a computer program (including program code) running on a computer device. For example, the blockchain-based data processing device 2 is an application software. The blockchain-based data processing device 2 can be used to execute the corresponding steps in the method provided in the embodiment of the present application. Figure 16 As shown, the blockchain-based data processing device 2 may include: a transaction receiving module 201, a transaction signature verification module 202, a transaction validation module 203 and an event execution module 204;

[0337] The transaction receiving module 201 is used to receive a first signature transaction sent by a resource service device in a resource business service system; the first signature transaction is constructed by the resource service device based on the first operation private key, the first signature content, the first Merkle path and the first approval signature list of the operation object i; the first signature content is determined by the resource service device based on the acquired space management request associated with N contract addresses, and the first signature content includes the Merkle tree root associated with the N contract addresses and the modification business event triggered for the N contract addresses; the first Merkle path refers to the path from the contract address i to the Merkle tree root; the space management request is used to instruct the M approval terminals associated with the business space to approve and sign the first signature content to obtain the approval signature information for the first signature content; the first approval signature list is constructed by the resource service device based on the approval signature information returned by the M approval terminals;

[0338] The transaction signature verification module 202 is configured to verify the first signed transaction using the first operation public key corresponding to the first operation private key to obtain a transaction signature verification result;

[0339] The transaction verification module 203 is configured to, when the transaction verification result indicates that the transaction verification is successful, perform transaction verification on the first signed transaction through the resource management contract i to obtain a transaction verification result; the transaction verification includes performing root verification on the Merkle tree root based on the first Merkle path and performing multi-signature verification on the first approval signature list;

[0340] The event execution module 204 is used to call the resource management contract i to execute the modification business event when the transaction verification result indicates that the transaction verification is successful.

[0341] The specific implementation of the transaction receiving module 201, the transaction signature verification module 202, the transaction verification module 203 and the event execution module 204 can be found in the above Figure 12The description of the specific process of the first consensus node processing the first signature transaction in the corresponding embodiment will not be repeated here.

[0342] The blockchain includes a first blockchain, and the blockchain where the resource management contract i is located is the first blockchain;

[0343] The transaction verification module 203 includes: an identification determination and splicing unit 2031, a Merkle tree root reconstruction unit 2032, a signature information restoration unit 2033 and a verification result determination unit 2034;

[0344] The identifier determination and splicing unit 2031 is configured to determine the chain identifier of the first blockchain as the first chain identifier through the resource management contract i, perform a first splicing process on the first chain identifier and the contract address i, and obtain first splicing processing information associated with the contract address i;

[0345] The Merkle root reconstruction unit 2032 is configured to perform hash calculation on the first splicing processing information to obtain a first hash calculation value of the first splicing processing information; determine, based on the first Merkle path, an associated verification node associated with the tree node where the contract address i is located; use the hash value on the associated verification node as the first associated hash value; reconstruct a Merkle tree root to be compared based on the first hash calculation value and the first associated hash value; and perform root verification on the Merkle tree root based on the Merkle tree root to be compared to obtain a root verification result;

[0346] The signature information restoration unit 2033 is configured to restore the approval signature information associated with the M approval terminals from the first approval signature list included in the transaction content of the first signature transaction, count the number of signatures associated with the restored approval signature information, and perform multi-signature verification on the first approval signature list based on the signature count to obtain a multi-signature verification result.

[0347] The verification result determination unit 2034 is used to determine the transaction verification result based on the root verification result and the multi-signature verification result.

[0348] Among them, there are M approval objects corresponding to M approval terminals, one approval object belongs to one approval group, and one approval group includes at least one approval object; the root verification result includes a root verification success result for indicating that the Merkle tree root to be compared is consistent with the Merkle tree root; the multi-signature verification result includes a multi-signature verification success result for indicating that the number of signature statistics reaches the multi-signature threshold indicated by the multi-signature verification; the number of signature statistics is determined by the number of groups in the approval group to which the approval objects participating in the approval signature belong;

[0349] The verification result determining unit 2034 is specifically configured to, when the root verification result includes a root verification success result and the multi-signature verification success result includes a multi-signature verification success result, use the root verification success result and the multi-signature verification success result as the transaction verification success result corresponding to the first signature transaction;

[0350] The verification result determining unit 2034 is further specifically configured to determine a transaction verification result based on a successful transaction verification result.

[0351] The blockchain includes a first blockchain, N resource management contracts corresponding to N contract addresses are deployed on the first blockchain, one contract address corresponds to one resource management contract, the N contract addresses include a contract address j, the resource management contract corresponding to the contract address j is a resource management contract j, j is a positive integer less than or equal to N, and j is not equal to i; the operation object corresponding to the contract address j is the operation object j, the first signature transaction is a transaction in the multiple signature transactions included in the target block, and the target block is a block to be uploaded to the first blockchain;

[0352] The device 2 further includes: a signature transaction adding module 205, a block consensus module 206 and a block chaining module 207;

[0353] The transaction receiving module 201 is further configured to receive a third signature transaction signed by the operation object j from the resource service device. The third signature transaction is constructed by the resource service device based on the third operation private key of the operation object j, the first signature content, the second Merkle path, and the first approval signature list when the third Merkle path from the contract address j to the Merkle tree root is determined.

[0354] The signature transaction adding module 205 is used to add the first signature transaction and the third signature transaction to the transaction pool of the first consensus node. When the transaction pool meets the transaction packaging conditions, multiple signature transactions including the first signature transaction and the third signature transaction are obtained from the transaction pool, and the multiple signature transactions are packaged into the target block.

[0355] Block consensus module 206 is used to perform block consensus on the target block and obtain a block consensus result; block consensus includes calling resource management contract i to execute the modification business event and calling resource management contract j to execute the modification business event;

[0356] The block chain module 207 is configured to chain the target block that has reached the block consensus to the first blockchain when the block consensus result indicates that the target block has reached the block consensus.

[0357] The specific implementation of the signature transaction adding module 205, the block consensus module 206 and the block chain module 207 can be found in the above Figure 12The specific process of achieving consensus on the target block in the corresponding embodiment will not be described in detail here. In addition, for the blockchain-based data processing device, the description of the same beneficial effects obtained by sampling the same method will not be described in detail here.

[0358] See Figure 17 , Figure 17 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. Figure 17 As shown, the computer device 1000 may include: a processor 1001, a network interface 1004 and a memory 1005. In addition, 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 realize the connection and communication between these components. The optional user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory, such as at least one disk memory. The memory 1005 may optionally be at least one storage device located away from the aforementioned processor 1001. As Figure 17 As shown, the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a device control application program.

[0359] exist Figure 17 In the computer device 1000 shown, the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to implement the above Figure 3 、 Figure 10 、 Figure 12 or Figure 13 The methods in the corresponding embodiments will not be described in detail here. In addition, the description of the beneficial effects of adopting the same methods will not be described in detail here either.

[0360] In addition, it should be pointed out that: the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores a computer program executed by the aforementioned blockchain-based data processing device 1 or blockchain-based data processing device 2, and the computer program includes program instructions. When the processor executes the program instructions, it can execute the aforementioned Figure 3 、 Figure 10 、 Figure 12 or Figure 13The description of the blockchain-based data processing method in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here. For technical details not disclosed in the computer storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application.

[0361] As an example, the above program instructions may be deployed on a computer device for execution, or deployed on multiple computer devices located at one location for execution, or executed on multiple computer devices distributed at multiple locations and interconnected by a communication network. Multiple computer devices distributed at multiple locations and interconnected by a communication network may constitute a blockchain consensus network.

[0362] The computer-readable storage medium can be the data processing device for the blockchain provided in any of the aforementioned embodiments, or the internal storage unit of the computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. Furthermore, the computer-readable storage medium can include both the internal storage unit and external storage device of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or is about to be output.

[0363] In addition, it should be noted that: the embodiment of the present application also provides a computer program product or computer program, which includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the above Figure 3 、 Figure 10 、 Figure 12 or Figure 13 The description of the blockchain-based data processing method described in the corresponding embodiment will not be repeated here. Furthermore, the description of the beneficial effects of the same method will not be repeated here. For technical details not disclosed in the computer-readable storage medium embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0364] For further information, see Figure 18 , Figure 18This is a schematic diagram of a blockchain-based data processing system provided by an embodiment of the present application. The blockchain-based data processing system 3 may include a consensus node 3a and a resource service device 3b. The resource service device 3b may be the above-mentioned Figure 3 、 Figure 10 or Figure 13 The resource service device in the corresponding embodiment, the consensus node 3a can be the above Figure 12 or Figure 13 The first consensus node in the corresponding embodiment can be any consensus node in the consensus network corresponding to the above-mentioned blockchain. In addition, the description of the beneficial effects of adopting the same method will not be repeated.

[0365] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0366] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A data processing method based on blockchain, characterized in that: The method is executed by a resource service device in a resource business service system, wherein the business space of the resource business service system includes N contract addresses, where N is a positive integer greater than 1, and the N contract addresses include a contract address i. The operation object corresponding to the contract address i is operation object i, and the resource management contract corresponding to the contract address i is the resource management contract i on the blockchain, where i is a positive integer less than or equal to N. The method includes: Obtaining a space management request associated with the N contract addresses; the first signature content carried in the space management request includes the Merkle tree root associated with the N contract addresses and a modification business event triggered for the N contract addresses; Sending the space management request to M approval terminals associated with the business space, so that the M approval terminals perform approval signatures on the first signed content to obtain approval signature information for the first signed content; M is a positive integer greater than 1; Obtain the approval signature information returned by the M approval terminals, construct a first approval signature list associated with the M approval terminals based on the obtained approval signature information, and determine a first Merkle path from the contract address i to the Merkle tree root; Obtain the first operation private key of the operation object i, and when a first signed transaction is constructed based on the first operation private key, the first signature content, the first Merkle path, and the first approval signature list, send the first signed transaction to the first consensus node running the resource management contract i; the first consensus node is used to verify the first signed transaction using the first operation public key corresponding to the first operation private key, and when the transaction verification is successful, perform transaction verification on the first signed transaction through the resource management contract i, and when the transaction verification is successful, call the resource management contract i to execute the modification business event; the transaction verification includes root verification of the Merkle tree root based on the first Merkle path and multi-signature verification of the first approval signature list.

2. The method according to claim 1, characterized in that The management terminal associated with the M approval terminals is the first management terminal; each of the M approval terminals is a terminal added centrally by the first management terminal for performing approval signatures for the N contract addresses; The obtaining of the space management request associated with the N contract addresses includes: receiving a system access request submitted by the first management terminal, and performing identity authentication on a management object corresponding to the first management terminal based on object access information carried in the system access request to obtain an identity authentication result; If the identity authentication result indicates that the management object has access rights to the resource business service system, returning a business service page provided by the resource business service system to the first management terminal; receiving a first management request sent by the first management terminal; the first management request is generated by the first management terminal in response to a centralized modification operation performed on the N contract addresses on the business service page, based on a modification business event corresponding to the centralized modification operation; configuring a spatial operation sequence number corresponding to the centralized modification operation based on the first management request; Obtain the Merkle tree root associated with the N contract addresses, use the Merkle tree root, the space operation sequence number, the modification timestamp corresponding to the modified business event, and the modified business event as the first signature content to be signed, and determine the space management request associated with the N contract addresses based on the first signature content.

3. The method according to claim 2, characterized in that The N contract addresses correspond to N resource management contracts; The configuring the spatial operation sequence number corresponding to the centralized modification operation based on the first management request includes: Obtaining a contract operation sequence number of each resource management contract in the N resource management contracts based on the first management request; Selecting a maximum contract operation sequence number from the contract operation sequence numbers of each resource management contract, and performing an incrementing process on the selected maximum contract operation sequence number to obtain the incremented maximum contract operation sequence number; The incremented maximum contract operation serial number is determined as the space operation serial number corresponding to the centralized modification operation.

4. The method according to any one of claims 1 to 3, characterized in that The N contract addresses are selected by the management object from the business service page provided by the business service system, the blockchain includes a first blockchain on which N resource management contracts corresponding to the N contract addresses are deployed, and the chain identifier of the first blockchain is a first chain identifier; The Merkle tree root includes a first Merkle tree root associated with the N contract addresses; The method further comprises: Concatenate the first chain identifier and each of the N contract addresses to obtain address concatenation information of each contract address; the address concatenation information of a contract address is obtained by concatenating the first chain identifier and a contract address; Perform hash transformation on the address splicing information of each contract address to obtain the address hash value corresponding to the address splicing information of each contract address; the address splicing information of one contract address corresponds to one address hash value; The address hash values corresponding to the address splicing information of each contract address are respectively used as leaf nodes of the first Merkle tree. Based on the leaf nodes of the first Merkle tree, the first Merkle tree is constructed, and the root node of the first Merkle tree is used as the first Merkle tree root associated with the N contract addresses.

5. The method according to any one of claims 1 to 3, characterized in that The N contract addresses include N1 first contract addresses and N2 second contract addresses; N=N1+N2, N1 and N2 are both positive integers, the blockchain includes a first blockchain on which N1 resource management contracts corresponding to the N1 first contract addresses are deployed, and a second blockchain on which N2 resource management contracts corresponding to the N2 second contract addresses are deployed, the chain identifier of the first blockchain is a first chain identifier, the chain identifier of the second blockchain is a second chain identifier, and the Merkle tree root includes a second Merkle tree root associated with the N1 first contract addresses and the N2 second contract addresses; The method further comprises: Taking each of the N1 first contract addresses as the first chain contract address, and concatenating the first chain identifier and the first chain contract address to obtain first address concatenation information of the first chain contract address; Use each of the N2 second contract addresses as the second chain contract address, and concatenate the second chain identifier and the second chain contract address to obtain the second address concatenation information of the second chain contract address; Performing a hash transformation on the first address splicing information to obtain a first address hash value corresponding to the first address splicing information, and performing a hash transformation on the second address splicing information to obtain a second address hash value corresponding to the second address splicing information; The first address hash value and the second address hash value are respectively used as leaf nodes of a second Merkle tree. Based on the leaf nodes of the second Merkle tree, a second Merkle tree is constructed, and the root node of the second Merkle tree is used as the second Merkle tree root associated with the N1 first contract addresses and the N2 second contract addresses.

6. The method according to claim 1, characterized in that The management terminal associated with the M approval terminals is a second management terminal, and the second management terminal is a target approval terminal among the M approval terminals; the target approval terminal is an approval terminal among the M approval terminals that has access rights to the resource business service system; The obtaining of the space management request associated with the N contract addresses includes: receiving a second management request sent by the target approval terminal; the second management request is generated by the target approval terminal in response to a centralized modification operation performed on the N contract addresses on a business service page, based on a modification business event corresponding to the centralized modification operation; the business service page is provided by an approval subject corresponding to the target approval terminal when accessing the resource business service system based on the access permission; configuring a spatial operation sequence number corresponding to the centralized modification operation based on the second management request; Obtain the Merkle tree root associated with the N contract addresses, use the Merkle tree root, the space operation sequence number, the modification timestamp corresponding to the modified business event, and the modified business event as the first signature content to be signed, and determine the space management request associated with the N contract addresses based on the first signature content.

7. The method according to claim 1, characterized in that The blockchain includes a first blockchain; the M approval terminals include a first approval terminal and a second approval terminal; the approval address of the first approval terminal is a first approval address, and the approval address of the second approval terminal is a second approval address; the first approval address and the second approval address are both on-chain registered addresses after registering the addresses on the first blockchain; the business modification event includes at least an approval object addition action and an approval address addition parameter; the approval object addition action refers to centrally adding a business approval object for approval signature to the N contract addresses, and the approval address addition parameter is a third approval address of the business approval object; The third approval address is the approval address to be registered on the first blockchain; The obtaining of the approval signature information returned by each approval terminal includes: receiving first approval signature information returned by the first approval terminal; the first approval signature information is obtained by the first approval terminal, when obtaining the first signed content based on the space management request, adding an action to the approval object, adding parameters to the approval address, and performing content approval on the Merkle tree root in the first signed content, and, upon completion of content approval, performing an approval signature on the first signed content using the first private key corresponding to the first approval address; receiving second approval signature information returned by the second approval terminal; the second approval signature information is obtained by the second approval terminal, when obtaining the first signed content based on the space management request, adding an action to the approval object, adding parameters to the approval address, and performing content approval on the Merkle tree root in the first signed content, and, upon completion of content approval, signing the first signed content with a second private key corresponding to the second approval address; the second private key is different from the first private key; The approval signature information returned by each approval terminal is determined based on the first approval signature information and the second approval signature information.

8. The method according to claim 1, characterized in that The blockchain includes a first blockchain; the approval address of each approval terminal in the M approval terminals is an on-chain registered address after the address is registered on the first blockchain, the M approval terminals include approval terminal m, m is a positive integer less than or equal to M, the modification business event includes at least an approval object removal action and an approval address removal parameter; the approval object removal action refers to collectively removing the approval objects corresponding to the approval terminal m used for approval signature for the N contract addresses, and the approval address removal parameter is used to indicate the removal of the approval address of the approval object corresponding to the approval terminal m on the first blockchain.

9. The method according to claim 1, characterized in that The blockchain includes a first blockchain, the resource management contract i corresponding to the contract address i is deployed on the first blockchain, the consensus node on the first blockchain is the first consensus node, the operation service component corresponding to the operation object i is deployed in the resource service device, and the operation terminal corresponding to the operation object i is the operation terminal i; The obtaining of the first operation private key of the operation object i, and constructing a first signed transaction based on the first operation private key, the first signature content, the first Merkle path, and the first approval signature list, and sending the first signed transaction to the first consensus node running the resource management contract i, includes: Determine the operation service component corresponding to the operation object i as operation service component i, use the first signature content, the first Merkle path, and the first approval signature list as the transaction content of a first transaction to be signed through the operation service component i, and when the first transaction to be signed is constructed based on the transaction content, send a transaction signature request for the first transaction to be signed to the operation terminal i; the transaction signature request is used to instruct the operation terminal i to generate a signature authorization instruction corresponding to the signature authorization operation in response to the signature authorization operation on the first transaction to be signed; receiving a signature authorization instruction returned by the operation terminal i, and obtaining a first operation private key of the operation object i from the resource business service system based on the signature authorization instruction; Signing the first transaction to be signed using the first operation private key of the operation object i to obtain transaction signature information for the first transaction to be signed; Based on the first transaction to be signed and the transaction signature information, a first signed transaction corresponding to the operation service component i is constructed and sent to the first consensus node; the first consensus node is used to verify the first signed transaction through the first operation public key when the first operation public key corresponding to the first operation private key is obtained, and when the transaction verification is successful, the resource management contract corresponding to the contract address i is used to verify the first signed transaction, and when the transaction verification is successful, the resource management contract corresponding to the contract address i is called to execute the modification business event.

10. The method according to claim 9, characterized in that The blockchain includes a second blockchain different from the first blockchain, the N contract addresses include a contract address k, where k is a positive integer less than or equal to N; the resource management contract corresponding to the contract address k is a resource management contract k, the resource management contract k is deployed on the second blockchain, the consensus node on the second blockchain is a second consensus node, and the operation object corresponding to the contract address k is an operation object k; The method further comprises: Determine a second Merkle path from the contract address k to the Merkle tree root; Obtain the second operation private key of the operation object k, and when a second signature transaction is constructed based on the second operation private key, the first signature content, the second Merkle path, and the first approval signature list, send the second signature transaction to the second consensus node; the second consensus node is used to verify the second signature transaction through the second operation public key corresponding to the second operation private key, and when the transaction verification is successful, perform transaction verification on the second signature transaction through the resource management contract k, and when the transaction verification is successful, call the resource management contract k to execute the modification business event; the transaction verification includes root verification of the Merkle tree root based on the second Merkle path and multi-signature verification of the first approval signature list.

11. The method according to claim 1, characterized in that The business modification event includes at least an approval object addition action and an approval address addition parameter; the approval object addition action refers to the centralized addition of business approval objects for approval signatures to the N contract addresses, and the approval address addition parameter is the third approval address of the business approval object; the third approval address is the approval address to be registered on the first blockchain; the first consensus node is used to add an approval management relationship between the business approval object and the contract address i when calling the resource management contract i to execute the business modification event, and when uploading the first signed transaction carrying the third approval address to the first blockchain based on the approval management relationship, record the modification success event information carrying the approval management relationship through the resource management contract i; The method further comprises: Obtain the modification success event information from the resource management contract i running on the first consensus node; Based on the approval management relationship in the modification success event information, generate modification prompt information for indicating that the business approval object has been used as the approval object associated with the contract address i; based on the modification prompt information and the approval terminal corresponding to the third approval address, update the M approval terminals associated with the business space to obtain K approval terminals associated with the business space, where K is a positive integer greater than M.

12. The method according to claim 11, characterized in that The blockchain includes a first blockchain, the asset management contract i corresponding to the contract address i is an asset transfer contract for performing asset transfer on the first blockchain, and the consensus node on the first blockchain is the first consensus node; The method further comprises: Receive an asset transfer event corresponding to an asset transfer operation triggered by a first business object for the asset transfer contract, and generate an asset transfer request for the asset transfer contract based on the resource transfer event; the second signature carried in the asset transfer request includes the contract address i and the asset transfer event, wherein the asset transfer event is used to instruct the transfer of the virtual assets of the first business object in the asset transfer contract to the second business object; Sending the asset transfer request to the K approval terminals, so that the K approval terminals perform approval signatures on the second signature content, and obtain approval signature information for the second signature content; Acquire the approval signature information returned by the K approval terminals, and construct a second approval signature list associated with the K approval terminals based on the acquired approval signature information; When an asset transfer signature transaction is constructed based on the first operation private key, the second signature content and the second approval signature list, the asset transfer signature transaction is sent to the first consensus node; the first consensus node is used to sign and verify the asset transfer signature transaction using the first operation public key corresponding to the first operation private key, and when the signature verification is successful, the asset transfer signature transaction is verified through the asset transfer contract, and when the transaction verification is successful, the asset transfer contract is called to execute the asset transfer event; the transaction verification includes address verification of the contract address i and multi-signature verification of the second approval signature list.

13. A data processing method based on blockchain, characterized in that: The method is executed by a first consensus node, which is a consensus node on a blockchain associated with a contract address i, wherein the contract address i is included in N contract addresses, and the N contract addresses are deployed in the business space of the resource business service system, where N is a positive integer greater than 1, and the operation object corresponding to the contract address i is operation object i, and the resource management contract corresponding to the contract address i is resource management contract i on the blockchain, where i is a positive integer less than or equal to N. The method includes: Receive a first signature transaction sent by a resource service device in the resource business service system; the first signature transaction is constructed by the resource service device based on the first operation private key, first signature content, first Merkle path and first approval signature list of the operation object i; the first signature content is determined by the resource service device based on the acquired space management request associated with the N contract addresses, and the first signature content includes the Merkle tree root associated with the N contract addresses and the modification business event triggered for the N contract addresses; the first Merkle path refers to the path from the contract address i to the Merkle tree root; the space management request is used to instruct the M approval terminals associated with the business space to approve and sign the first signature content, and obtain approval signature information for the first signature content; the first approval signature list is constructed by the resource service device based on the approval signature information returned by the M approval terminals; Performing transaction verification on the first signed transaction using the first operation public key corresponding to the first operation private key, and obtaining a transaction verification result; When the transaction verification result indicates that the transaction verification is successful, the resource management contract i is used to perform transaction verification on the first signed transaction to obtain a transaction verification result; the transaction verification includes performing root verification on the Merkle tree root based on the first Merkle path and performing multi-signature verification on the first approval signature list; When the transaction verification result indicates that the transaction verification is successful, the resource management contract i is called to execute the modification business event.

14. The method according to claim 13, characterized in that The blockchain includes a first blockchain, and the blockchain where the resource management contract i is located is the first blockchain; The first signed transaction is verified by the resource management contract i to obtain a transaction verification result, including: Determine, by the resource management contract i, the chain identifier of the first blockchain as the first chain identifier, perform a first concatenation process on the first chain identifier and the contract address i, and obtain first concatenation processing information associated with the contract address i; Performing a hash value calculation on the first splicing processing information to obtain a first calculated hash value of the first splicing processing information; determining, based on the first Merkle path, an associated verification node associated with the tree node where the contract address i is located; using the hash value on the associated verification node as a first associated hash value; reconstructing a Merkle tree root to be compared based on the first calculated hash value and the first associated hash value; performing the root verification on the Merkle tree root based on the Merkle tree root to be compared to obtain a root verification result; Restore the approval signature information associated with the M approval terminals from the first approval signature list included in the transaction content of the first signature transaction, count the number of signatures associated with the restored approval signature information, and perform the multi-signature verification on the first approval signature list based on the counted number of signatures to obtain a multi-signature verification result; Based on the root verification result and the multi-signature verification result, the transaction verification result is determined.

15. The method according to claim 14, characterized in that The M approval terminals correspond to M approval objects, each approval object belongs to an approval group, and an approval group includes at least one approval object; the root verification result includes a root verification success result indicating that the Merkle tree root to be compared is consistent with the Merkle tree root; the multi-signature verification result includes a multi-signature verification success result indicating that the signature statistics reach the multi-signature threshold indicated by the multi-signature verification; the signature statistics are determined by the number of groups in the approval group to which the approval objects participating in the approval signature belong; Determining the transaction verification result based on the root verification result and the multi-signature verification result includes: When the root verification result includes the root verification success result, and the multi-signature verification result includes the multi-signature verification success result, the root verification success result and the multi-signature verification success result are used as the transaction verification success result corresponding to the first signature transaction; Based on the successful transaction verification result, the transaction verification result is determined.

16. The method according to claim 13, characterized in that The blockchain includes a first blockchain, on which N resource management contracts corresponding to the N contract addresses are deployed, where one contract address corresponds to one resource management contract, the N contract addresses include a contract address j, the resource management contract corresponding to the contract address j is resource management contract j, j is a positive integer less than or equal to N, and j is not equal to i; the operation object corresponding to the contract address j is operation object j, the first signed transaction is a transaction in multiple signed transactions included in a target block, and the target block is a block to be uploaded to the first blockchain; The method further comprises: Receive a third signature transaction signed by the operation object j and sent by the resource service device; the third signature transaction is constructed by the resource service device based on the third operation private key of the operation object j, the first signature content, the second Merkle path, and the first approval signature list when the third Merkle path from the contract address j to the Merkle tree root is determined; Adding the first signed transaction and the third signed transaction to the transaction pool of the first consensus node; when the transaction pool meets the transaction packaging conditions, obtaining the multiple signed transactions including the first signed transaction and the third signed transaction from the transaction pool, and packaging the multiple signed transactions into the target block; Performing block consensus on the target block to obtain a block consensus result; the block consensus includes calling the resource management contract i to execute the modification business event and calling the resource management contract j to execute the modification business event; When the block consensus result indicates that the target block has reached a block consensus, the target block that has reached a block consensus is uploaded to the first blockchain.

17. A data processing device based on blockchain, characterized in that: The device runs on a resource service device in a resource business service system, wherein the business space of the resource business service system includes N contract addresses, where N is a positive integer greater than 1, and the N contract addresses include a contract address i. The operation object corresponding to the contract address i is the operation object i, and the resource management contract corresponding to the contract address i is the resource management contract i on the blockchain, where i is a positive integer less than or equal to N. The device includes: A management request acquisition module, configured to acquire space management requests associated with the N contract addresses; the first signature content carried in the space management request includes the Merkle tree root associated with the N contract addresses and the modification business event triggered for the N contract addresses; a management request sending module, configured to send the space management request to M approval terminals associated with the business space, so that the M approval terminals perform approval signatures on the first signed content to obtain approval signature information for the first signed content; M is a positive integer greater than 1; A signature list construction module is configured to obtain the approval signature information returned by the M approval terminals, construct a first approval signature list associated with the M approval terminals based on the obtained approval signature information, and determine a first Merkle path from the contract address i to the Merkle tree root; A signature transaction sending module is used to obtain the first operation private key of the operation object i, and when a first signature transaction is constructed based on the first operation private key, the first signature content, the first Merkel path and the first approval signature list, the first signature transaction is sent to the first consensus node running the resource management contract i; the first consensus node is used to verify the first signature transaction through the first operation public key corresponding to the first operation private key, and when the transaction verification is successful, the first signature transaction is verified through the resource management contract i, and when the transaction verification is successful, the resource management contract i is called to execute the modification business event; the transaction verification includes root verification of the Merkel tree root based on the first Merkel path and multi-signature verification of the first approval signature list.

18. A data processing device based on blockchain, characterized in that: The device runs on a first consensus node, which is a consensus node on a blockchain associated with a contract address i. The contract address i is included in N contract addresses, and the N contract addresses are deployed in the business space of the resource business service system. N is a positive integer greater than 1. The operation object corresponding to the contract address i is operation object i. The resource management contract corresponding to the contract address i is resource management contract i on the blockchain. i is a positive integer less than or equal to N. The device includes: A transaction receiving module is used to receive a first signature transaction sent by a resource service device in the resource business service system; the first signature transaction is constructed by the resource service device based on the first operation private key, first signature content, first Merkle path and first approval signature list of the operation object i; the first signature content is determined by the resource service device based on the acquired space management request associated with the N contract addresses, and the first signature content includes the Merkle tree root associated with the N contract addresses and the modification business event triggered for the N contract addresses; the first Merkle path refers to the path from the contract address i to the Merkle tree root; the space management request is used to instruct the M approval terminals associated with the business space to approve and sign the first signature content to obtain approval signature information for the first signature content; the first approval signature list is constructed by the resource service device based on the approval signature information returned by the M approval terminals; a transaction signature verification module, configured to verify the first signed transaction using the first operation public key corresponding to the first operation private key, and obtain a transaction signature verification result; A transaction verification module is configured to, when the transaction verification result indicates that the transaction verification is successful, perform transaction verification on the first signed transaction through the resource management contract i to obtain a transaction verification result; the transaction verification includes performing root verification on the Merkle tree root based on the first Merkle path and performing multi-signature verification on the first approval signature list; The event execution module is used to call the resource management contract i to execute the modification business event when the transaction verification result indicates that the transaction verification is successful.

19. A computer device, characterized in that: including memory and processor; The memory is connected to the processor, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method according to any one of claims 1 to 16.

20. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which is suitable for being loaded and executed by a processor, so that a computer device having the processor executes the method according to any one of claims 1 to 16.

Images