A blockchain-based data processing method, device, and readable storage medium

Abstract

Embodiments of the present application disclose a data processing method and device based on a blockchain and a readable storage medium. The method comprises: obtaining a first token identifier and a second token identifier according to a resource fusion request; calling a resource fusion function according to the resource fusion request, and determining, based on the resource fusion function, a resource fusion permission between a first virtual resource represented by the first token identifier and a second virtual resource represented by the second token identifier in the blockchain; if the resource fusion permission is a resource fusion allowed permission and the first virtual resource is a fused virtual resource, fusing a second attribute state value corresponding to the second virtual resource into a first attribute state value corresponding to the first virtual resource to obtain an updated attribute state value of the first virtual resource; and calling a resource destruction function according to the updated attribute state value, and destroying the second virtual resource in the blockchain based on the resource destruction function. The present application can reduce the waste of blockchain storage space.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a data processing method, device and readable storage medium based on blockchain. Background Technology

[0002] Due to the decentralized and immutable nature of blockchain technology, it can provide ownership certificates for various off-chain items (including digital and physical items) with virtual resources that have unique characteristics as the certificate type, and store and distribute them in a distributed manner.

[0003] In real-world scenarios, two off-chain items can be integrated. For example, in a video game, in-game resources can be incorporated into equipment. If virtual resources corresponding to the equipment (virtual resource 1) and virtual resources corresponding to the in-game resources (virtual resource 2) have already been issued on the blockchain network, then to accommodate the integration of the off-chain equipment and the in-game resources, existing technology would issue virtual resource 3 on the blockchain network. This virtual resource 3 would represent the certificate for the equipment incorporating the in-game resources. Clearly, existing technology for integrating off-chain items would store virtual resource 1, virtual resource 2, and virtual resource 3 on the blockchain, resulting in excessive storage space wasted on the blockchain. Summary of the Invention

[0004] This application provides a blockchain-based data processing method, device, and readable storage medium, which can reduce the waste of blockchain storage space.

[0005] One embodiment of this application provides a blockchain-based data processing method, including: Obtain a resource fusion request, and obtain the first certificate identifier and the second certificate identifier based on the resource fusion request; Based on the resource fusion request, the resource fusion function in the smart contract is invoked. Based on the resource fusion function, the resource fusion permission between the first virtual resource represented by the first warrant identifier and the second virtual resource represented by the second warrant identifier is determined in the blockchain. If the resource fusion permission is the resource fusion allowed permission and the first virtual resource is the virtual resource to be fused, then the second attribute status value corresponding to the second virtual resource is merged into the first attribute status value corresponding to the first virtual resource to obtain the updated attribute status value corresponding to the first virtual resource. The resource destruction function in the smart contract is called based on the updated attribute state value. Based on the resource destruction function, the second virtual resource is destroyed in the blockchain.

[0006] One embodiment of this application provides a blockchain-based data processing device, including: The request acquisition module is used to acquire resource fusion requests and obtain the first certificate identifier and the second certificate identifier based on the resource fusion requests. The first determining module is used to call the resource fusion function in the smart contract according to the resource fusion request, and based on the resource fusion function, determine the resource fusion permission between the first virtual resource represented by the first warrant identifier and the second virtual resource represented by the second warrant identifier in the blockchain. The state fusion module is used to merge the second attribute state value corresponding to the second virtual resource into the first attribute state value corresponding to the first virtual resource if the resource fusion permission is the resource fusion allowed permission and the first virtual resource is the virtual resource to be fused, so as to obtain the updated attribute state value corresponding to the first virtual resource. The resource destruction module is used to call the resource destruction function in the smart contract based on the updated attribute status value, and to destroy the second virtual resource in the blockchain based on the resource destruction function.

[0007] The first determining module includes: The first determining unit is used to determine, based on the resource fusion function, the first metadata corresponding to the first virtual resource represented by the first warrant identifier and the second metadata corresponding to the second virtual resource represented by the second warrant identifier in the blockchain. The first determining unit is further configured to determine the first object identifier corresponding to the first virtual resource and the second object identifier corresponding to the second virtual resource; The second determining unit is used to determine the resource fusion permission between the first virtual resource and the second virtual resource based on the first metadata, the second metadata, the first object identifier, and the second object identifier.

[0008] The resource fusion request also includes a fusion request identifier; The second determining unit includes: The first determining subunit is configured to determine the resource fusion permission between the first virtual resource and the second virtual resource as a resource fusion rejection permission if the fusion request identifier is different from at least one of the first object identifier or the second object identifier. The second determining subunit is used to determine the resource fusion permission based on the first metadata and the second metadata if the fusion request identifier is the same as the first object identifier and the second object identifier.

[0009] The second determined subunit includes: The type comparison subunit is used to obtain the first resource type in the first metadata and the second resource type in the second metadata, and compare the first resource type and the second resource type. The permission determination subunit is used to determine the resource fusion permission as the resource fusion denial permission if the first resource type is the same as the second resource type. The permission determination subunit is also used to determine resource fusion permissions based on the attribute status values ​​in the first metadata and the attribute status values ​​in the second metadata if the first resource type and the second resource type are different.

[0010] The second determining subunit further includes: The resource determination subunit is used to determine the first virtual resource as the virtual resource to be merged and the second virtual resource as the virtual resource to be merged if the resource fusion permission is the resource fusion allow permission, the first resource type is the type of resource to be merged, and the second resource type is the type of resource to be merged.

[0011] The attribute status values ​​in the first metadata include the fusion threshold and the first fusion history value; the attribute status values ​​in the second metadata include the attribute fusion consumption value. The permission determination subunit is specifically used to determine the remaining value of the first virtual resource to be merged based on the merging threshold and the first merging historical value. The permission determination sub-unit is also specifically used to compare the remaining value to be merged with the attribute fusion consumption value. If the remaining value to be merged is less than the attribute fusion consumption value, the resource fusion permission is determined to be a resource fusion rejection permission. The permission determination sub-unit is also specifically used to determine the resource fusion permission as the resource fusion allowed permission if the remaining value to be merged is equal to or greater than the attribute fusion consumption value.

[0012] The first attribute status value includes the first merged historical value and the first current business attribute value, and the second attribute status value includes the attribute fusion consumption value and the business attribute value to be merged. The state fusion module includes: The first addition unit is used to add the attribute fusion consumption value to the first fused history value to obtain the updated fused history value; The second adding unit is used to add the business attribute value to be integrated to the first current business attribute value to obtain the updated business attribute value; The third determining unit is used to determine the updated merged historical value and the updated business attribute value as the updated attribute status value.

[0013] The second adding unit includes: The third determining subunit is used to determine the business attribute represented by the first current business attribute value and the business attribute represented by the business attribute value to be merged. The first adding subunit is used to add the business attribute value to be merged to the first business attribute value if the business attribute represented by the first current business attribute value includes the business attribute represented by the business attribute value to be merged, thereby obtaining an updated business attribute value; the business attribute represented by the first business attribute value is the same as the business attribute represented by the business attribute value to be merged; the first business attribute value belongs to the first current business attribute value. The second addition subunit is used to create a second business attribute value if the business attribute represented by the first current business attribute value does not include the business attribute represented by the business attribute value to be merged; the business attribute represented by the second business attribute value is the same as the business attribute represented by the business attribute value to be merged. The second adding sub-unit is also used to add the business attribute value to be merged to the second business attribute value, and add the second business attribute value with the business attribute value to be merged to the first current business attribute value to obtain the updated business attribute value.

[0014] The first added subunit includes: The attribute addition sub-unit is used to add the business attribute value to be merged to the first business attribute value to obtain the intermediate business attribute value. The attribute randomization sub-unit is used to obtain random numbers. These random numbers are then used to randomly process intermediate business attribute values ​​to obtain updated business attribute values.

[0015] Among them, the second virtual resource has a fusion duration threshold; The blockchain-based data processing device also includes: The second determining module is used to determine the fusion time for the second attribute state value to be fused into the first attribute state value; The duration comparison module is used to compare the fusion duration with the fusion duration threshold. If the fusion duration is equal to the fusion duration threshold, the second attribute status value is deleted from the third attribute status value corresponding to the first virtual resource, and the fourth attribute status value corresponding to the first virtual resource is obtained. The third attribute status value refers to the current attribute status value corresponding to the first virtual resource when the fusion duration is equal to the fusion duration threshold.

[0016] The second attribute status value includes the attribute fusion consumption value and the business attribute value to be fused; the third attribute status value includes the second fused historical value and the second current business attribute value. The duration comparison module includes: The first deletion unit is used to delete the attribute fusion consumption value from the second fused history value to obtain the third fused history value. The second deletion unit is used to delete the business attribute value to be merged from the second current business attribute value to obtain the third current business attribute value. The fourth determining unit is used to determine the third merged historical value and the third current business attribute value as the fourth attribute status value corresponding to the first virtual resource.

[0017] The blockchain-based data processing device also includes: The request acquisition module is also used to acquire resource issuance requests; the resource issuance request includes resource details information, which includes the issuance object identifier, the target virtual resource, the resource type corresponding to the target virtual resource, and the fifth attribute status value corresponding to the target virtual resource; the target virtual resource is either a first virtual resource or a second virtual resource; The third determination module is used to determine the resource issuance authority of the target virtual resource based on the resource type corresponding to the target virtual resource and the status value of the fifth attribute. The third determination module is also used to determine the target certificate identifier corresponding to the target virtual resource based on the resource details information when the resource issuance permission is the resource issuance permission. The resource issuance module is used to execute the resource issuance function in the smart contract based on the resource details and the target warrant identifier; The resource issuance module is also used to issue target virtual resources to the issuing object identifier based on the resource issuance function.

[0018] The third determining module includes: The fifth determining unit is used to determine the resource issuance permission as the resource issuance permission if the resource type corresponding to the target virtual resource is a fused resource type and the fifth attribute status value includes the attribute fusion consumption value and the business attribute value to be fused. The sixth determining unit is used to determine the resource issuance permission as the resource issuance permission if the resource type corresponding to the target virtual resource is the type of resource to be merged, and the fifth attribute status value includes the merging threshold, the initial merging historical value, and the initial business attribute value.

[0019] This application provides a computer device, including: a processor, a memory, and a network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store computer programs, and the processor is used to call the computer programs so that the computer device executes the methods in the embodiments of this application.

[0020] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded by a processor and executed by the method described in this application.

[0021] One aspect of this application provides a computer program product, which includes a computer program stored in a computer-readable storage medium; a processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the method described in this application.

[0022] In this embodiment, upon receiving a resource fusion request including a first warrant identifier and a second warrant identifier, a blockchain node can invoke a resource fusion function in a smart contract based on the request. Based on this function, the resource fusion permission between the first virtual resource represented by the first warrant identifier and the second virtual resource represented by the second warrant identifier can be determined within the blockchain. Furthermore, if the resource fusion permission is a resource fusion allowed permission and the first virtual resource is the fused virtual resource, the second attribute state value corresponding to the second virtual resource can be merged into the first attribute state value corresponding to the first virtual resource to obtain an updated attribute state value corresponding to the first virtual resource. Further, based on the updated attribute state value, a resource destruction function in the smart contract can be invoked, and the second virtual resource can be destroyed within the blockchain. As can be seen above, this embodiment provides a blockchain-based resource fusion method. This method allows the fusion of the second attribute state value corresponding to the second virtual resource into the first attribute state value corresponding to the first virtual resource, thus achieving the fusion of the second virtual resource into the first virtual resource without the need to issue new virtual resources. Clearly, by updating attribute status values ​​and destroying the second virtual resource as described in this application, the waste of blockchain storage space can be reduced. Attached Figure Description

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

[0024] Figure 1 This is a schematic diagram of a system architecture provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. Figure 1 ; Figure 3 This application provides an example of a blockchain-based data processing scenario. Figure 1 ; Figure 4This application provides an example of a blockchain-based data processing scenario. Figure 2 ; Figure 5 This application provides an example of a blockchain-based data processing scenario. Figure 3 ; Figure 6 This application provides an example of a blockchain-based data processing scenario. Figure 4 ; Figure 7 This application provides an example of a blockchain-based data processing scenario. Figure 5 ; Figure 8 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. Figure 2 ; Figure 9 This application provides an example of a blockchain-based data processing scenario. Figure 6 ; Figure 10 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. Figure 3 ; Figure 11 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application; Figure 12 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0026] To facilitate understanding, the following brief explanations are provided for some of the terms: 1. Blockchain: In a narrow sense, blockchain is a chain-like data structure with blocks as the basic unit. Digital digests are used in blocks to verify previously obtained transaction history, making it suitable for the tamper-proof and scalable requirements of distributed ledger scenarios. In a broader sense, blockchain also refers to the distributed ledger technology implemented using the blockchain structure, including distributed consensus, privacy and security protection, peer-to-peer communication technology, network protocols, and smart contracts. The goal of blockchain is to realize a distributed data record ledger that only allows additions, not deletions. The underlying basic structure of the ledger is a linear linked list. The linked list consists of a series of "blocks," with each subsequent block recording the hash value of the previous block. The validity of each block (and the transactions within it) can be quickly verified by calculating the hash value. If a node in the network proposes to add a new block, the block must be confirmed through a consensus mechanism.

[0027] 2. Blockchain Nodes: Blockchain networks divide nodes into consensus nodes (also known as core nodes) and synchronization nodes (which can include data nodes and light nodes). Consensus nodes are responsible for the consensus process across the entire blockchain network; synchronization nodes are responsible for synchronizing the ledger information of the consensus nodes, i.e., synchronizing the latest block data. Both consensus and synchronization nodes include network communication components in their internal structure, because a blockchain network is essentially a peer-to-peer (P2P) network, requiring communication with other nodes in the blockchain network through P2P components. Resources and services in the blockchain network are distributed across various nodes; information transmission and service implementation occur directly between nodes, without the need for intermediaries or centralized servers (third parties).

[0028] 3. Smart Contract: A smart contract is a computer protocol designed to disseminate, verify, or execute contracts in an information-based manner. In a blockchain system, a smart contract (or simply contract) is code that all nodes on the blockchain can understand and execute, capable of performing arbitrary logic and obtaining results. In practical applications, smart contracts are managed and tested through transactions on the blockchain. Each transaction is equivalent to a Remote Procedure Call (RPC) request to the blockchain system. If a smart contract is like an executable program, the blockchain is like the operating system that provides the runtime environment. A blockchain can contain multiple contracts (such as the resource fusion function and resource issuance function in this application), distinguished by contract identity (ID), identifier, or name.

[0029] 4. Contract Execution: By initiating a transaction (such as the resource fusion request in this application), users can invoke contracts already deployed on the blockchain (such as the resource fusion function in this application). Each node in the blockchain system runs the same contract. For contracts that need to read data, they access their own ledger. Ultimately, each node verifies the consistency of the execution results (consensus). If the execution results are consistent, each node stores the necessary results in its own ledger and returns the results to the user.

[0030] 5. Virtual Resources: These are digital products, referring to off-chain items as on-chain products within a blockchain network. The virtual resources in this application can represent ownership of off-chain items; therefore, virtual resources in this embodiment can be understood as warrants. For example, if the off-chain item is a piece of land, the virtual resource represents ownership of that land; if the off-chain item is a game skin, the virtual resource represents ownership of that game skin. This embodiment does not limit the total number of virtual resources; it can be 1, for example, a piece of land has only one virtual resource (i.e., land ownership); or it can be a positive integer greater than 1, for example, a game developer produces 10 identical game skins and issues virtual resources corresponding to each of the 10 game skins on the blockchain.

[0031] 6. Token Identifier: Used to identify off-chain items as on-chain products within the blockchain network, i.e., identifiers used to identify virtual resources. If the total number of virtual resources is greater than 1, for example, if a game developer produces 10 identical game skins, then the total number of virtual resources corresponding to the 10 identical game skins is equal to 10. In this case, the 10 virtual resources have the same identifier in the blockchain network, but each virtual resource can have its own index identifier to distinguish them. Therefore, the token identifier in this application embodiment can carry an index identifier. For example, if the index identifier is 1, it represents the first virtual resource among the aforementioned 10 virtual resources.

[0032] 7. Metadata: In this embodiment of the application, metadata refers to information describing virtual resources. For example, first metadata is used to describe the resource type and first attribute status value of the first virtual resource.

[0033] Please see Figure 1 , Figure 1 This is a schematic diagram of a system architecture provided in an embodiment of this application. For example... Figure 1As shown, the system architecture can be a blockchain network, which may include a consensus network 101 and a synchronization network 102. Nodes in the synchronization network 102 can be called synchronization nodes. Synchronization nodes primarily perform business execution and do not participate in the accounting consensus process. They obtain block data from the consensus network 101 through identity authentication. The consensus network 101 can also be called the core network, and its nodes are called consensus nodes. Consensus nodes possess all the data. The consensus network 101 and the synchronization network 102 can reside in different network environments. Typically, the consensus network 101 is in a private network, while the synchronization network 102 is in a public network, and the two interact through routing boundaries.

[0034] It is understood that the consensus network 101 described above may include one or more consensus nodes; there is no limit to the number of consensus nodes here. Please see also Figure 1 Consensus network 101 may include consensus node 1011, consensus node 1012, ..., consensus node 1013.

[0035] It is understood that the aforementioned synchronization network 102 may include one or more synchronization nodes; the number of synchronization nodes will not be limited here. Please refer to [link to previous document]. Figure 1 The synchronization network 102 may include synchronization node 1021, synchronization node 1022, synchronization node 1023, ..., synchronization node 1024 and synchronization node 1025.

[0036] Each blockchain node (including the consensus node in consensus network 101 and the synchronization node in synchronization network 102) can receive transaction data sent by the client during normal operation, generate blocks based on the received transaction data, and then perform block on-chain processing. It is understood that in the specific embodiments of this application, data related to user information (such as the issuer identifier and fusion request identifier) ​​is involved. 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 related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0037] To ensure data interoperability between blockchain nodes, data connections can exist between each blockchain node. For example, there is a data connection between consensus node 1011 and consensus node 1012, a data connection between consensus node 1011 and consensus node 1013, a data connection between synchronization node 1021 and synchronization node 1023, and so on. Furthermore, there are data connections between consensus network 101 and synchronization network 102, such as a data connection between consensus node 1011 and synchronization node 1022, a data connection between consensus node 1012 and synchronization node 1023, and so on.

[0038] It is understandable that blockchain nodes can transmit data or blocks through the aforementioned data connections. These data connections between blockchain nodes can be based on node identifiers. Each blockchain node in the network has a corresponding node identifier, and each node can store the node identifiers of other connected blockchain nodes. This allows the node to broadcast acquired data or generated blocks to other blockchain nodes based on their node identifiers. For example, consensus node 1011 can maintain a list of node identifiers, which stores the node names and identifiers of other blockchain nodes, as shown in Table 1.

[0039] Table 1

[0040] The node identifier can be an Internet Protocol (IP) address used for interconnecting networks, or any other information that can be used to identify a blockchain node in a blockchain network.

[0041] Assuming the node identifier of consensus node 1011 is FFFFF, then consensus node 1011 can send a data synchronization request to synchronization node 1021 through the node identifier CCCCC, and synchronization node 1021 can know that the data synchronization request was sent by consensus node 1011 through the node identifier FFFFF. Similarly, synchronization node 1023 can send transaction data A to consensus node 1011 through the node identifier FFFFF, and consensus node 1011 can know that transaction data A was sent by synchronization node 1023 through the node identifier EEEEE. Data transmission between other nodes is also like this, so it will not be described in detail.

[0042] It is understood that the above data connection is not limited to the connection method. It can be connected directly or indirectly through wired communication, or directly or indirectly through wireless communication, or through other connection methods. This application does not impose any restrictions on this.

[0043] Understandable, Figure 1The blockchain nodes in the blockchain network include, but are not limited to, terminal devices or servers. These servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The terminal devices include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The terminal devices and servers can be connected directly or indirectly via wired or wireless means; this application embodiment does not impose any limitations on this.

[0044] Further, please see Figure 2 , Figure 2 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. Figure 1 This blockchain-based data processing method can be used by blockchain nodes (including...). Figure 1 The synchronization nodes and consensus nodes in the process execute the commands. Figure 2 As shown, the blockchain-based data processing method may include at least the following steps S101-S104.

[0045] Step S101: Obtain the resource fusion request, and obtain the first certificate identifier and the second certificate identifier according to the resource fusion request.

[0046] For details, please refer to the following: Figure 3 , Figure 3 This application provides an example of a blockchain-based data processing scenario. Figure 1 The fusion request object 201a can represent a fusion request user operating the fusion request node 20a. The fusion request node 20a includes, but is not limited to, terminal devices or servers. These servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The terminal devices include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft.

[0047] like Figure 3As shown, the fusion request node 20a can display an item display page 204a for the fusion request object 201a. The item display page 204a can display a first item and a second item. In this embodiment, the form of the first item and the second item is not limited. They can be digital items, such as pictures, music, game equipment, etc., or they can be physical items, such as a piece of land, a house, etc. The form and quantity of items can be set according to the actual application scenario.

[0048] The first item and the second item in this application embodiment have a fusion relationship. The fusion relationship in this application embodiment means that the first item and the second item can be combined to enhance the business attributes of the fused item. For example, the first item is electronic equipment (fused item), and the second item is video game consumable resources (fused item). By fusing video game consumable resources into electronic equipment, the business attributes of electronic equipment (such as defense value and attack value) can be enhanced. For example, the first item is a car (fused item), and the second item is a car part (fused item). By installing car parts into a car, the business attributes of the car (such as speed and safety) can be enhanced.

[0049] This application embodiment can generate two types of resource fusion requests based on the scenario. One type of resource fusion request carries a first certificate identifier and a second certificate identifier. For ease of description, the resource fusion request carrying the first certificate identifier and the second certificate identifier is referred to as the first resource fusion request. The other type of resource fusion request carries a first item identifier for representing a first item and a second item identifier for representing a second item. To distinguish the above-mentioned first resource fusion request, the resource fusion request carrying the first item identifier and the second item identifier is referred to as the second resource fusion request.

[0050] Please see details. Figure 3 If the fusion request object 201a triggers the item fusion control 205a on the item display page 204a, then the fusion request node 20a responds to the trigger operation of the item fusion control 205a, obtaining a first item identifier to represent the first item, a second item identifier to represent the second item, and a fusion request identifier to represent the fusion request object 201a. The first item identifier can be the item's number or any other information that can uniquely identify the first item. For the meaning of the second item identifier, please refer to the understanding of the meaning of the first item identifier. The fusion request identifier can be the account of the fusion request object 201a, or any other information that can uniquely identify the fusion request object 201a.

[0051] In a scenario where a first index table 20c is stored, the fusion request node 20a can retrieve the first index table 20c. For example... Figure 3As shown, the first index table 20c may include index keys generated by certificate identifiers and index values ​​generated by item identifiers. Specifically, it may include a first item identifier corresponding to a first item, and a first certificate identifier with an index relationship to the first item identifier; a second item identifier corresponding to a second item, and a second certificate identifier with an index relationship to the second item identifier; a third item identifier corresponding to a third item, and a third certificate identifier with an index relationship to the third item identifier. The certificate identifier in this application is used to represent the identifier of an off-chain item as an on-chain product (representing ownership of the off-chain item) in the blockchain network. It is understood that the first index table 20c is sent by the blockchain network to the fusion request node 20a, and all item identifiers in the first index table 20c are held by the fusion request identifier.

[0052] The fusion request node 20a can determine from the first index table 20c a first certificate identifier that has an index relationship with the first item identifier and a second certificate identifier that has an index relationship with the second item identifier. Further, it generates a first resource fusion request including the first certificate identifier, the second certificate identifier, and a fusion request identifier. The fusion request node 20a sends the first resource fusion request to the blockchain node 20b, i.e., the blockchain node 20b obtains the first resource fusion request. At this time, the blockchain node 20b can obtain the first certificate identifier and the second certificate identifier from the first resource fusion request.

[0053] Optionally, to ensure the security of the blockchain network, the blockchain network does not send the first index table 20c to the fusion request node 20a. In this case, the fusion request node 20a does not store the first index table 20c locally. Therefore, the fusion request node 20c can generate a second resource fusion request based on the first item identifier, the second item identifier, and the fusion request identifier, and then send the second resource fusion request to the blockchain node 20b.

[0054] Blockchain node 20b can obtain the fusion request identifier, the first item identifier, and the second item identifier from the second resource fusion request. Based on the fusion request identifier, blockchain node 20b obtains a first index table 20c that has an index relationship with the fusion request identifier. This application embodiment does not limit the method by which blockchain node 20b obtains the first index table 20c; it can obtain the first index table 20c from a local database or from the blockchain network. The process by which blockchain node 20b obtains the first certificate identifier and the second certificate identifier based on the first index table 20c, the first item identifier, and the second item identifier can be referred to the process described above where fusion request node 20a obtains the first certificate identifier and the second certificate identifier, and therefore will not be repeated here.

[0055] In summary, this application embodiment can generate two types of resource fusion requests based on actual application scenarios: a first resource fusion request and a second resource fusion request. The first resource fusion request includes a first certificate identifier and a second certificate identifier. Therefore, after obtaining the first resource fusion request, blockchain node 20b can directly obtain the first certificate identifier and the second certificate identifier, thus improving the certificate acquisition efficiency of blockchain node 20b and reducing its workload. The second resource fusion request is generated on the basis that the fusion request node 20a does not store the first index table 20c. It includes a first item identifier and a second item identifier. Therefore, after obtaining the second resource fusion request, blockchain node 20b can determine the first certificate identifier and the second certificate identifier based on the first item identifier, the second item identifier, and the first index table 20c. This method of obtaining the certificate identifier can ensure the security of the certificate data in the blockchain network.

[0056] Understandable, Figure 3 The interfaces and controls shown are merely some forms of representation for reference. In actual business scenarios, developers can make relevant designs according to product requirements. This application does not limit the specific forms of the interfaces and controls involved.

[0057] Step S102: Based on the resource fusion request, call the resource fusion function in the smart contract, and based on the resource fusion function, determine the resource fusion permission between the first virtual resource represented by the first warrant identifier and the second virtual resource represented by the second warrant identifier in the blockchain.

[0058] Specifically, based on the resource fusion function, the first metadata corresponding to the first virtual resource represented by the first certificate identifier and the second metadata corresponding to the second virtual resource represented by the second certificate identifier are determined in the blockchain; the first object identifier corresponding to the first virtual resource and the second object identifier corresponding to the second virtual resource are determined; and the resource fusion permission between the first virtual resource and the second virtual resource is determined according to the first metadata, the second metadata, the first object identifier and the second object identifier.

[0059] The resource fusion request also includes a fusion request identifier. The specific process of determining the resource fusion permission between the first virtual resource and the second virtual resource based on the first metadata, the second metadata, the first object identifier, and the second object identifier may include: if the fusion request identifier is different from at least one of the first object identifier or the second object identifier, then the resource fusion permission between the first virtual resource and the second virtual resource is determined to be a resource fusion denial permission; if the fusion request identifier is the same as both the first object identifier and the second object identifier, then the resource fusion permission is determined based on the first metadata and the second metadata.

[0060] The specific process of determining resource fusion permissions based on the first metadata and the second metadata may include: obtaining the first resource type in the first metadata and the second resource type in the second metadata, and comparing the first resource type and the second resource type; if the first resource type and the second resource type are the same, then the resource fusion permission is determined to be a resource fusion denial permission; if the first resource type and the second resource type are different, then the resource fusion permission is determined based on the attribute status value in the first metadata and the attribute status value in the second metadata.

[0061] If the resource fusion permission is the resource fusion allowed permission, and the first resource type is the type of resource to be fused, and the second resource type is the type of fused resource, then the first virtual resource is determined to be the virtual resource to be fused, and the second virtual resource is the virtual resource to be fused.

[0062] The attribute status values ​​in the first metadata include the fusion threshold and the first fusion history value; the attribute status values ​​in the second metadata include the attribute fusion consumption value; the specific process of determining resource fusion permissions based on the attribute status values ​​in the first metadata and the second metadata may include: determining the remaining value of the first virtual resource to be fused based on the fusion threshold and the first fusion history value; comparing the remaining value to be fused with the attribute fusion consumption value; if the remaining value to be fused is less than the attribute fusion consumption value, then the resource fusion permission is determined to be a resource fusion denial permission; if the remaining value to be fused is equal to or greater than the attribute fusion consumption value, then the resource fusion permission is determined to be a resource fusion allow permission.

[0063] With the development of blockchain technology, more and more digital and physical goods are being processed on the blockchain, that is, off-chain items are being issued as on-chain items (virtual resources) on the blockchain network. However, current resource standards mainly regulate processes such as minting (issuance), transfer, and destruction, but lack regulations for the fusion of multiple virtual resources, which is not conducive to the expansion of practical scenarios. Based on this, this application proposes a method for fusion of virtual resources and proposes a resource fusion function. Please refer to Table 2, which shows the interface of the resource fusion function provided in this application embodiment in a smart contract and the definition events of the function.

[0064] Table 2

[0065] Please see also Figure 4 , Figure 4 This application provides an example of a blockchain-based data processing scenario. Figure 2 .like Figure 4As shown, blockchain node 20b obtains a first certificate identifier and a second certificate identifier based on a resource fusion request. According to the resource fusion request, blockchain node 20b can access smart contract 20d. The smart contract 20d described in this embodiment may include a resource fusion function 20f, and therefore, this resource fusion function 20f can be called. Further, blockchain node 20b inputs both the first certificate identifier and the second certificate identifier into the resource fusion function 20f. Based on the resource fusion function 20f, blockchain node 20b can obtain first resource description information 201e and second resource description information 202e.

[0066] like Figure 4 As shown, the first resource description information 201e may include a first certificate identifier, a first object identifier, and first metadata; the second resource description information 202e may include a second certificate identifier, a second object identifier, and second metadata. The first object identifier represents the object identifier holding the first virtual resource with the first certificate identifier, and the second object identifier represents the object identifier holding the second virtual resource with the second certificate identifier. The first metadata represents the detailed description information of the first virtual resource, and the second metadata represents the detailed description information of the second virtual resource. Further, the blockchain node 20b compares the first object identifier, the second object identifier, and the resource fusion identifier to obtain a resource comparison result; it also compares the first metadata and the second metadata to obtain a metadata comparison result. Then, based on the resource comparison result and the metadata comparison result, it determines the resource fusion permission between the first virtual resource and the second virtual resource.

[0067] Among them, blockchain node 20b can first compare the first object identifier, the second object identifier, and the resource fusion identifier, and then compare the first metadata and the second metadata; or it can first compare the first metadata and the second metadata, and then compare the first object identifier, the second object identifier, and the resource fusion identifier; or it can simultaneously compare the identifier and the metadata.

[0068] If the resource fusion identifier differs from at least one of the first object identifier or the second object identifier, then blockchain node 20b can determine that the fusion permission between the first virtual resource and the second virtual resource is a resource fusion rejection permission. For example, if the first object identifier is object 2000, meaning object 1000 holds the first virtual resource, and the second object identifier is object 1000, meaning object 2000 holds the second virtual resource, but the fusion request identifier is object 2001, then blockchain node 20b can determine that the resource fusion request was not initiated by the object holding both the first and second virtual resources. Therefore, the resource fusion request is an illegal request, and the blockchain node 20b can refuse to process the resource fusion request. As another example, if the first object identifier is object 3000, the second object identifier is object 3001, and the fusion request identifier is object 3000, then blockchain node 20b can determine that object 3000 initiated the resource fusion request. However, object 3000 only holds the first virtual resource and not the second virtual resource, therefore it does not have fusion permission, and the blockchain node 20b refuses to process the resource fusion request.

[0069] The metadata (including first metadata and second metadata) provided in this application embodiment includes the following fields: a Type field, a Slots field, and a Property field. The Type field indicates the resource type of the virtual resource. It is important to emphasize that the merged resource type and the merged resource type described in this application embodiment are not directly determined by the Type field, but rather by the association between the first resource type and the second resource type to determine whether the first resource type is a merged resource type and whether the second resource type is a merged resource type. Optionally, the Slots field allows the blockchain node to further determine whether the first resource type is a merged resource type or a merged resource type; please refer to the following description of the Slots field for details.

[0070] For example, the first virtual resource represents the certificate of electronic equipment, and the first resource type is the equipment type. The second virtual resource represents the certificate of resources consumed by video games, and the second resource type is the game resource type. Based on the relationship between the equipment type and the game resource type, the blockchain node can determine that the equipment type is the merged resource type, the game resource type is the merged resource type, the first virtual resource (i.e., the certificate of electronic equipment) is the merged virtual resource, and the second virtual resource (i.e., the certificate of resources consumed by video games) is the merged virtual resource.

[0071] For example, the first virtual resource represents the certificate of ownership of a car, and the first resource type is the car type; the second virtual resource represents the certificate of ownership of a car part, and the second resource type is the part type. Based on the car type and the relationship between the parts, the blockchain node can determine that the car type is the merged resource type, the part type is the merged resource type, the first virtual resource (i.e. the car certificate) is the merged virtual resource, and the second virtual resource (i.e. the car part certificate) is the merged virtual resource.

[0072] For example, the first virtual resource represents the certificate for electronic equipment, and this first resource type is the equipment type; the second virtual resource represents the certificate for a physical house, and this second resource type is the house type. Since there is no correlation between the equipment type and the house type, the blockchain node can determine that the equipment type belongs to neither the merged virtual resource nor the merged resource type, and it can also determine that the house type belongs to neither the merged virtual resource nor the merged resource type. Furthermore, the blockchain node can determine that the first virtual resource belongs to neither the merged virtual resource nor a virtual resource, and it can also determine that the second virtual resource belongs to neither the merged virtual resource nor a virtual resource.

[0073] It is understood that the above description is merely an example for the purpose of facilitating description and understanding in this application embodiment. In actual application, the resource type can be determined according to the actual application scenario. This application embodiment does not limit the resource type.

[0074] The slot field indicates the fusion capability of virtual resources. As a prerequisite for fusion, this slot field can include two fields: a threshold (Total) field and a history (Used) field. The value of the threshold field (i.e., the fusion threshold) is determined when the virtual resource is issued or minted, indicating the maximum value that the virtual resource can be fused. The value of the history field can change; typically, this field has a value of 0 when the virtual resource is issued or minted, and its value increases as the virtual resource is fused with other virtual resources. As a prerequisite for fusion, the slot field includes a need field. The need field's value is determined when the virtual resource is issued or minted, indicating the slot value required to fuse the virtual resource with other virtual resources.

[0075] The business attribute field indicates the business attributes and attribute status values ​​of the virtual resource. As a prerequisite for being merged into a virtual resource, the value of this business attribute field can be increased during the merging process. The value of this business attribute field is determined when the virtual resource is created, as a prerequisite for merging virtual resources.

[0076] For the detailed process of blockchain nodes comparing the first and second metadata, please refer to [link / reference needed]. Figure 5 , Figure 5 This is a schematic diagram of a data processing scenario based on blockchain provided in an embodiment of this application. A blockchain node obtains first metadata 201g and second metadata 202g. The first metadata 201g includes a type field, a slot field, and a business attribute field. The type field in the first metadata 201g indicates the first resource type of the first virtual resource. The slot field in the first metadata 201g includes a threshold field and a history field. The threshold field indicates the fusion threshold of the first virtual resource, such as... Figure 5 The example threshold is 5, and this history field is used to indicate the first merged historical value of the first virtual resource, such as... Figure 5 The historical value in the example is 1; the business attribute field in the first metadata 201g is used to indicate the business attributes of the first virtual resource, as well as the attribute status value (i.e., the first current business attribute value) corresponding to the business attributes. Figure 5 Example: The first virtual resource has three business attributes: Business Attribute A, Business Attribute B, and Business Attribute C. The attribute status value for Business Attribute A is 10, for Business Attribute B it is 2, and for Business Attribute C it is 3. Assume the first virtual resource is a certificate for electronic equipment; Business Attribute A can be an attack attribute, Business Attribute B can be a defense attribute, and Business Attribute C can be a chemical attribute. Please see again. Figure 5 The second metadata 202g includes a type field, a slot field, and a business attribute field. The type field in the second metadata 202g is used to indicate the second resource type of the second virtual resource. The slot field in the second metadata 202g includes a consumption field, which is used to indicate the slot value required for the fusion of the second virtual resource. Figure 5 Example: The consumption value of the second virtual resource is 1; the business attribute field in the second metadata 202g indicates the business attributes of the second virtual resource, as well as the attribute status value (i.e., the business attribute value to be merged) corresponding to the business attributes. Figure 5 Example: The second virtual resource has a business attribute D, and the attribute state value corresponding to business attribute D is equal to 3. Assume the second virtual resource is a resource consumed by a video game, and business attribute D can be a physical business attribute.

[0077] Please see again. Figure 5The blockchain node compares the first resource type with the second resource type. If the first and second resource types are the same, for example, both are equipment resources, then the resource fusion permission between the first and second virtual resources can be determined as a resource fusion rejection permission. If the first and second resource types are different, for example, the first resource type is equipment and the second resource type is a game consumable resource, then the blockchain node can determine, based on the association between the first and second virtual resources, that the first virtual resource is the virtual resource to be fused and the second virtual resource is the virtual resource to be fused. Furthermore, the blockchain node obtains the fusion threshold and the first fusion historical value from the first metadata 201g, such as... Figure 5 Given an example threshold of 5 and a historical value of 1, based on the fusion threshold and the first fused historical value, the blockchain node can determine that the remaining value of the first virtual resource after fusion is equal to (5-1), i.e., 4. Further, the blockchain node obtains the attribute fusion consumption value from the second metadata 202g, such as... Figure 5 Example consumption value = 1.

[0078] Furthermore, the blockchain node compares the remaining value to be merged with the attribute fusion consumption value. If the remaining value to be merged is less than the attribute fusion consumption value, it indicates that the merging capability of the merged virtual resource (such as the first virtual resource in the example of this application embodiment) is less than the fusion consumption capability of the merged virtual resource (such as the second virtual resource in the example of this application embodiment). In this case, the blockchain node determines the resource fusion permission as a resource fusion rejection permission. If the remaining value to be merged is equal to or greater than the attribute fusion consumption value, it indicates that the merging capability of the merged virtual resource can match the fusion consumption capability of the merged virtual resource. In this case, the blockchain node determines the resource fusion permission as a resource fusion allow permission.

[0079] In summary, this application embodiment can determine, based on a resource fusion request, first metadata describing a first virtual resource, second metadata describing a second virtual resource, a first object identifier holding the first virtual resource, and a second object identifier holding the second virtual resource. By comparing the first object identifier, the second object identifier, and the fusion request identifier, and by comparing the first metadata and the second metadata, the resource fusion permission between the first virtual resource and the second virtual resource can be determined. Furthermore, this application embodiment proposes a slot field and a business attribute field, which can describe the fusion capability (i.e., attribute fusion consumption value) or the fusion capability (i.e., fusion threshold and fusion remaining value) of a virtual resource, and describe the business attributes of the virtual resource and the attribute status values ​​corresponding to the business attributes. The above description information can not only determine resource fusion permission but also realize the resource fusion of the first virtual resource and the second virtual resource; please refer to the description of step S103 for details.

[0080] Step S103: If the resource fusion permission is the resource fusion allowed permission and the first virtual resource is the virtual resource to be fused, then the second attribute status value corresponding to the second virtual resource is merged into the first attribute status value corresponding to the first virtual resource to obtain the updated attribute status value corresponding to the first virtual resource.

[0081] Specifically, the first attribute status value includes the first merged historical value and the first current business attribute value, and the second attribute status value includes the attribute fusion consumption value and the business attribute value to be merged; the attribute fusion consumption value is added to the first merged historical value to obtain the updated merged historical value; the business attribute value to be merged is added to the first current business attribute value to obtain the updated business attribute value; the updated merged historical value and the updated business attribute value are determined as the updated attribute status value.

[0082] The specific process of adding the business attribute value to be merged to the first current business attribute value to obtain the updated business attribute value may include: determining the business attribute represented by the first current business attribute value and the business attribute represented by the business attribute value to be merged; if the business attribute represented by the first current business attribute value includes the business attribute represented by the business attribute value to be merged, then the business attribute value to be merged is added to the first business attribute value to obtain the updated business attribute value; the business attribute represented by the first business attribute value is the same as the business attribute represented by the business attribute value to be merged; the first business attribute value belongs to the first current business attribute value; if the business attribute represented by the first current business attribute value does not include the business attribute represented by the business attribute value to be merged, then a second business attribute value is created; the business attribute represented by the second business attribute value is the same as the business attribute represented by the business attribute value to be merged; the business attribute value to be merged is added to the second business attribute value, and the second business attribute value with the added business attribute value to be merged is added to the first current business attribute value to obtain the updated business attribute value.

[0083] The specific process of adding the business attribute value to be integrated to the first business attribute value to obtain the updated business attribute value may include: adding the business attribute value to be integrated to the first business attribute value to obtain the intermediate business attribute value; obtaining a random number, and using the random number to randomly process the intermediate business attribute value to obtain the updated business attribute value.

[0084] As described in step S102, while determining the resource fusion permission between the first virtual resource and the second virtual resource, the blockchain node can also determine whether the first virtual resource is a fused virtual resource or a fused virtual resource, and whether the second virtual resource is a fused virtual resource or a fused virtual resource. For ease of description and understanding, this embodiment uses the example of the first virtual resource being the fused virtual resource and the second virtual resource being the fused virtual resource when the resource fusion permission is a resource fusion permitted permission. It is understood that if the first virtual resource is a fused virtual resource and the second virtual resource is a fused virtual resource, the subsequent processing in this scenario is similar to that when the first virtual resource is a fused virtual resource and the second virtual resource is a fused virtual resource, therefore, this embodiment will not elaborate further. Please refer to the following processing procedure for when the first virtual resource is a fused virtual resource and the second virtual resource is a fused virtual resource.

[0085] If the resource fusion permission is the resource fusion allowed permission and the first virtual resource is the virtual resource to be fused, then the blockchain node will fuse the second attribute status value corresponding to the second virtual resource into the first attribute status value corresponding to the first virtual resource to obtain the updated attribute status value corresponding to the first virtual resource. The specific process is as follows: The first metadata includes the first attribute status value corresponding to the first virtual resource, which includes the first fused historical value and the first current business attribute value described in step S102. The second metadata includes the second attribute status value corresponding to the second virtual resource, which includes the attribute fusion consumption value and the business attribute value to be fused described in step S102. Further, the blockchain node adds the attribute fusion consumption value to the first fused historical value to obtain the updated fused historical value. It can be understood that the updated fused historical value is greater than the first fused historical value. The blockchain node adds the business attribute value to be fused to the first current business attribute value to obtain the updated business attribute value. Further, the blockchain node determines the updated fused historical value and the updated business attribute value as the updated attribute status value.

[0086] Clearly, after the resource fusion operation, the first token identifier of the first virtual resource (i.e., the fused virtual resource) remains unchanged. However, the first fused historical value is incremented by the attribute fusion consumption value of the second virtual resource (i.e., the fused virtual resource). Updating the fused historical value indicates that the fusion capability of the first virtual resource has decreased. Furthermore, the first current business attribute value is added to the business attribute value to be fused. Updating the business attribute value indicates that the business attributes of the first virtual resource have been enhanced. The second virtual resource will be destroyed through the resource destruction function. That is, once on-chain resource fusion is performed, it is an irreversible operation, which will enhance the business attributes of the fused virtual resource while permanently losing the fused virtual resource. It is understandable that the first virtual resource, as the fused virtual resource, can be fused with other virtual resources multiple times, i.e., fused a second time. The fusion process is the same as the first fusion process.

[0087] For ease of understanding, please refer to the following: Figure 6 , Figure 6 This is a schematic diagram illustrating a blockchain-based data processing scenario provided in an embodiment of this application. For example... Figure 6 As shown, the first resource description information 201h of the first virtual resource includes the first certificate identifier, the first resource type, and the fusion threshold (e.g., ...). Figure 6 The threshold in the middle is 5), the first historical value to be fused (such as...) Figure 6 The historical value in the data is 0), and the first current business attribute value (such as...) Figure 6 In this context, A=10; B=3; C=4. For the meanings of A, B, and C, please refer to the text above. Figure 5 (Explanation in the text); The second resource description information 202h of the second virtual resource includes the second certificate identifier, the second resource type, and the attribute fusion consumption value (such as...). Figure 6 The consumption value in the middle is 1) and the attribute value of the business to be integrated (such as Figure 6 (D=2 in the example).

[0088] When the resource fusion permission between the first virtual resource and the second virtual resource is determined to be a resource fusion permitted permission, and the first virtual resource is the virtual resource to be fused, such as Figure 6 As shown, the blockchain node adds the attribute fusion consumption value of the second virtual resource to the first fusion history value of the first virtual resource, thus obtaining the updated fusion history value of the first virtual resource, as follows. Figure 6 The historical value in the first resource description information 203h is 1. Simultaneously, the blockchain node adds the business attribute value to be merged from the second virtual resource to the first current business attribute value of the first virtual resource, obtaining the updated business attribute value of the first virtual resource, such as... Figure 6The first virtual description information 203h contains the "Business Attributes: (A=10; B=3; C=4; D=2)". When merging the second attribute state value into the first attribute state value, the blockchain node calls the resource destruction function to destroy the second virtual resource, including destroying the second resource description information 202h.

[0089] Subsequently, the blockchain node receives another resource fusion request. Based on this request, the third and first warrant identifiers can be identified. Furthermore, the blockchain node can determine that the third virtual resource represented by the third warrant identifier is the fused virtual resource, and the first virtual resource represented by the first warrant identifier is the fused virtual resource. From the third resource description information 204h, it is known that the attribute fusion consumption value corresponding to the third virtual resource is 3, and it has business attribute B with a value of 4. From the first resource description information 203h, it is known that the remaining value of the first virtual resource to be fused is 4. Therefore, the resource fusion permission between the two is a resource fusion permitted permission. Further, the blockchain node adds the attribute fusion consumption value of the third virtual resource (i.e., the third resource description information) to the business attribute value (A=10; B=3; C=4; D=2) corresponding to the first virtual resource, obtaining the business attribute value (A=10; B=7; C=4; D=2) corresponding to the first virtual resource. It is understandable that the above process is the same as the process of merging the second virtual resource into the first virtual resource, except that the processing object is changed from the second virtual resource to the first virtual resource.

[0090] Subsequently, the blockchain node receives the resource fusion request for the third time. Based on this request, the fourth and first warrant identifiers can be identified. Furthermore, the blockchain node can determine that the third virtual resource represented by the fourth warrant identifier is the fused virtual resource, and the first virtual resource represented by the first warrant identifier is the fused virtual resource. From the fourth resource description information 206h, it is known that the attribute fusion consumption value corresponding to the fourth virtual resource is 3, and it has business attribute D with a value of 2. From the first resource description information 205h, it is known that the remaining value of the first virtual resource to be fused is 1. Therefore, the resource fusion permission between the two is a resource fusion rejection permission, and the blockchain node refuses to process the current resource fusion request.

[0091] To enhance the appeal and interest of resource integration, this application introduces a random number mechanism. This application does not limit the method for determining the random number, but includes, but is not limited to, adding the value of the business attribute to be integrated to the first business attribute value to obtain an intermediate business attribute value, such as... Figure 6The business attribute value (2) of business attribute D in the example first resource description information 203h is obtained by taking the intermediate business attribute value as the intermediate value and distributing the intermediate value normally; or by selecting the intermediate value probabilistically. Optionally, in the blockchain, it can be submitted through a two-stage transaction and the hash of the block in which the first-stage transaction is placed can be used as a random factor for calculation; or a random factor can be introduced in the form of a decentralized oracle, and then the random factor is used as a weight to be weighted with the business attribute value to be merged, and then superimposed with the business attribute value corresponding to the first virtual resource to obtain the updated business attribute value. For ease of understanding, please refer to the following: Figure 7 , Figure 7 This application provides an example of a blockchain-based data processing scenario. Figure 5 The blockchain node first obtains the random factor, then multiplies the business attribute value to be merged of the second virtual resource with the random factor, and finally adds the business attribute value multiplied by the random factor to the corresponding business attribute value of the first virtual resource to obtain the updated business attribute value.

[0092] In summary, the entity holding both the virtual resource to be merged and the object merging the virtual resource can choose to merge two virtual resources into one. While preserving the business attributes of the merged virtual resource, the business attributes of the merged virtual resource can be expanded, thus enhancing business capabilities. Furthermore, this embodiment uses a merging threshold to limit the merging capability of the merged virtual resource, preventing unlimited merging that could lead to an expansion of its business attributes. In addition, this embodiment can introduce a probabilistic mechanism to introduce unpredictability into the changes in business attributes during resource merging, increasing the enjoyment of the process.

[0093] Step S104: Call the resource destruction function in the smart contract according to the updated attribute status value, and destroy the second virtual resource in the blockchain based on the resource destruction function. For details, please refer to step S103 regarding... Figure 6 The description of that will not be repeated here.

[0094] In this embodiment, upon receiving a resource fusion request including a first warrant identifier and a second warrant identifier, a blockchain node can invoke a resource fusion function in a smart contract based on the request. Based on this function, the resource fusion permission between the first virtual resource represented by the first warrant identifier and the second virtual resource represented by the second warrant identifier can be determined within the blockchain. Furthermore, if the resource fusion permission is a resource fusion allowed permission and the first virtual resource is the fused virtual resource, the second attribute state value corresponding to the second virtual resource can be merged into the first attribute state value corresponding to the first virtual resource to obtain an updated attribute state value corresponding to the first virtual resource. Further, based on the updated attribute state value, a resource destruction function in the smart contract can be invoked, and the second virtual resource can be destroyed within the blockchain. As can be seen above, this embodiment provides a blockchain-based resource fusion method. This method allows the fusion of the second attribute state value corresponding to the second virtual resource into the first attribute state value corresponding to the first virtual resource, thus achieving the fusion of the second virtual resource into the first virtual resource without the need to issue new virtual resources. Clearly, by updating attribute status values ​​and destroying the second virtual resource in this application, not only can the resource integration process be simplified on the blockchain, but the waste of blockchain storage space can also be reduced.

[0095] Please see Figure 8 , Figure 8 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. Figure 2 This blockchain-based data processing method can be used by blockchain nodes (including...). Figure 1 The synchronization nodes and consensus nodes in the process execute the commands. Figure 8 As shown, the method may include at least the following steps.

[0096] Step S201: Obtain the resource fusion request, and obtain the first certificate identifier and the second certificate identifier according to the resource fusion request.

[0097] Step S202: Based on the resource fusion request, the resource fusion function in the smart contract is invoked. Based on the resource fusion function, the resource fusion permission between the first virtual resource represented by the first warrant identifier and the second virtual resource represented by the second warrant identifier is determined in the blockchain.

[0098] Step S203: If the resource fusion permission is the resource fusion allowed permission and the first virtual resource is the virtual resource to be fused, then the second attribute status value corresponding to the second virtual resource is merged into the first attribute status value corresponding to the first virtual resource to obtain the updated attribute status value corresponding to the first virtual resource.

[0099] Step S204: Call the resource destruction function in the smart contract according to the updated attribute status value, and destroy the second virtual resource in the blockchain based on the resource destruction function.

[0100] For the specific implementation process of steps S201-S204, please refer to the above text. Figure 2 Steps S101-S104 in the corresponding embodiments will not be described in detail here.

[0101] Step S205: Determine the fusion time for the second attribute state value to be merged into the first attribute state value.

[0102] Specifically, it is understandable that in real life, some off-chain items have an effective fusion time. For example, after a car part is added to a car, it will be updated after the car (or the car part) has been running for a period of time; similarly, after a video game resource is added to an electronic device, it becomes invalid after one hour. Based on this, this application proposes a fusion time threshold, whereby the blockchain node records the fusion moment when the second attribute state value is successfully fused to the first attribute state value, and then monitors the fusion time in real time. Please also refer to... Figure 9 , Figure 9 This is a schematic diagram illustrating a blockchain-based data processing scenario provided in an embodiment of this application. For the meanings of the second resource description information 801a and the first resource description information 802a, please refer to the above text. Figure 6 The descriptions in [the original text] are omitted here. Figure 8 As shown, at the first moment, the blockchain node merges the second attribute state value of the second virtual resource with the first attribute state value of the first virtual resource to obtain the updated attribute state value corresponding to the first virtual resource. Based on the updated attribute state value, the first resource description information 802a is updated, and the blockchain node can obtain the first resource description information 803a. Simultaneously, the blockchain node records the merging time (i.e., the first moment) and the second attribute state value merged into the first attribute state value at the first moment in the first resource description information 803a, and detects the merging duration.

[0103] Step S206: Compare the fusion duration with the fusion duration threshold. If the fusion duration equals the fusion duration threshold, delete the second attribute status value from the third attribute status value corresponding to the first virtual resource to obtain the fourth attribute status value corresponding to the first virtual resource. The third attribute status value refers to the current attribute status value corresponding to the first virtual resource when the fusion duration equals the fusion duration threshold.

[0104] Specifically, the second attribute status value includes the attribute fusion consumption value and the business attribute value to be fused; the third attribute status value includes the second fused historical value and the second current business attribute value; the attribute fusion consumption value is removed from the second fused historical value to obtain the third fused historical value; the business attribute value to be fused is removed from the second current business attribute value to obtain the third current business attribute value; the third fused historical value and the third current business attribute value are determined as the fourth attribute status value corresponding to the first virtual resource.

[0105] It is understandable that the first virtual resource, as the virtual resource being merged, can be continuously merged with other virtual resources, such as... Figure 2 As described in step S103 of the corresponding embodiment, the fusion process and the process of reducing the attribute state value (e.g., the second attribute state value) corresponding to the fused virtual resource to the fusion duration threshold are independent of each other and can be processed in parallel. Therefore, during the process of detecting the duration of the fusion of the second attribute state value to the first attribute state value, the first virtual resource may be fused with other virtual resources, such as the third virtual resource and the fourth virtual resource, and may also reduce other virtual resources that have reached the fusion duration threshold, such as the fifth virtual resource and the sixth virtual resource.

[0106] In this embodiment of the application, during the process of a blockchain node detecting the fusion time of the second attribute state value merging into the first attribute state value, no other virtual resources were merged or deleted. Please refer to the following example. Figure 9 At the second moment, the blockchain node determines that the fusion duration equals the fusion duration threshold. Therefore, it subtracts the attribute fusion consumption value from the second fused historical value to obtain the third fused historical value, such as... Figure 9 The historical value (=1) in the first resource description information 903a is subtracted from the consumption value (=1) recorded in the first resource description information 903a, so the historical value in the first resource description information 804a = 0; the blockchain node deletes the business attribute value to be merged from the second current business attribute value to obtain the third current business attribute value, such as... Figure 9 The business attribute value (=5) corresponding to business attribute B in the first resource description information 903a is subtracted from the business attribute value (=2) corresponding to business attribute B recorded in the first resource description information 903a, so the business attribute value (=3) corresponding to business attribute B in the first resource description information 804a is 3.

[0107] It is understandable that different virtual resources may have different fusion duration thresholds, which can be set according to the actual application scenario.

[0108] In this embodiment, upon receiving a resource fusion request including a first warrant identifier and a second warrant identifier, a blockchain node can invoke a resource fusion function in a smart contract based on the request. Based on this function, the resource fusion permission between the first virtual resource represented by the first warrant identifier and the second virtual resource represented by the second warrant identifier can be determined within the blockchain. Furthermore, if the resource fusion permission is a resource fusion allowed permission and the first virtual resource is the fused virtual resource, the second attribute state value corresponding to the second virtual resource can be merged into the first attribute state value corresponding to the first virtual resource to obtain an updated attribute state value corresponding to the first virtual resource. Further, based on the updated attribute state value, a resource destruction function in the smart contract can be invoked, and the second virtual resource can be destroyed within the blockchain. As can be seen above, this embodiment provides a blockchain-based resource fusion method. This method allows the fusion of the second attribute state value corresponding to the second virtual resource into the first attribute state value corresponding to the first virtual resource, thus achieving the fusion of the second virtual resource into the first virtual resource without the need to issue new virtual resources. Clearly, by updating attribute status values ​​and destroying the second virtual resource in this application, not only can the resource integration process be simplified on the blockchain, but the waste of blockchain storage space can also be reduced.

[0109] Please see Figure 10 , Figure 10 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. Figure 3 This blockchain-based data processing method can be used by blockchain nodes (including...). Figure 1 The synchronization nodes and consensus nodes in the process execute the commands. Figure 10 As shown, the method may include at least the following steps.

[0110] Step S301: Obtain a resource issuance request; the resource issuance request includes resource details information, which includes the issuance object identifier, the target virtual resource, the resource type corresponding to the target virtual resource, and the fifth attribute status value corresponding to the target virtual resource; the target virtual resource is either the first virtual resource or the second virtual resource.

[0111] Specifically, it is understandable that each virtual resource held by each issuing object identifier in the blockchain network must be issued to its own object identifier (such as a user address) in advance by the issuing object identifier.

[0112] Step S302: Determine the resource issuance permissions of the target virtual resource based on the resource type and the fifth attribute status value corresponding to the target virtual resource.

[0113] Specifically, if the resource type corresponding to the target virtual resource is a merged resource type, and the fifth attribute status value includes the attribute fusion consumption value and the business attribute value to be merged, then the resource issuance permission is determined to be the resource issuance permission; if the resource type corresponding to the target virtual resource is a merged resource type, and the fifth attribute status value includes the merged threshold, the initial merged historical value, and the initial business attribute value, then the resource issuance permission is determined to be the resource issuance permission.

[0114] If the target virtual resource is the first virtual resource, then the resource type corresponding to the target virtual resource is the merged virtual resource. If the fifth attribute status value includes the merge threshold and the initial merge history value (usually 0), then the blockchain node can determine that the resource issuance permission of the target virtual resource is the resource issuance permission.

[0115] If the target virtual resource is a second virtual resource, then the resource type corresponding to the target virtual resource is a merged virtual resource. If the fifth attribute status value includes the attribute fusion consumption value and the business attribute value to be merged, then the blockchain node can determine that the resource issuance permission of the target virtual resource is the resource issuance permission.

[0116] Step S303: When the resource issuance permission is the resource issuance permitted permission, determine the target certificate identifier corresponding to the target virtual resource based on the resource details information.

[0117] Step S304: Execute the resource issuance function in the smart contract based on the resource details and the target warrant identifier. Step S305: Based on the resource issuance function, issue the target virtual resource to the issuance object identifier.

[0118] Specifically, as described in steps S303-S305, based on the issuing object identifier, the item identifier to be issued corresponding to the target virtual resource, and the total quantity to be issued, the blockchain node generates a target warrant identifier for the target virtual resource. According to the target warrant identifier, the issuing object identifier, and the total quantity to be issued, the blockchain node executes the resource issuance function in the smart contract. Based on the resource issuance function, the blockchain node issues the target virtual resource, with an issuance quantity equal to the total quantity to be issued and carrying the target warrant identifier, to the issuing object identifier.

[0119] Step S306: Obtain the resource fusion request, and obtain the first certificate identifier and the second certificate identifier according to the resource fusion request.

[0120] Step S307: Based on the resource fusion request, call the resource fusion function in the smart contract, and based on the resource fusion function, determine the resource fusion permission between the first virtual resource represented by the first warrant identifier and the second virtual resource represented by the second warrant identifier in the blockchain.

[0121] Step S308: If the resource fusion permission is the resource fusion allowed permission and the first virtual resource is the virtual resource to be fused, then the second attribute status value corresponding to the second virtual resource is merged into the first attribute status value corresponding to the first virtual resource to obtain the updated attribute status value corresponding to the first virtual resource.

[0122] Step S309: Call the resource destruction function in the smart contract according to the updated attribute status value, and destroy the second virtual resource in the blockchain based on the resource destruction function.

[0123] For details on the implementation of steps S306-S309, please refer to the above text. Figure 2 Steps S101-S104 in the corresponding embodiments will not be described in detail here.

[0124] In this embodiment, upon receiving a resource fusion request including a first warrant identifier and a second warrant identifier, a blockchain node can invoke a resource fusion function in a smart contract based on the request. Based on this function, the resource fusion permission between the first virtual resource represented by the first warrant identifier and the second virtual resource represented by the second warrant identifier can be determined within the blockchain. Furthermore, if the resource fusion permission is a resource fusion allowed permission and the first virtual resource is the fused virtual resource, the second attribute state value corresponding to the second virtual resource can be merged into the first attribute state value corresponding to the first virtual resource to obtain an updated attribute state value corresponding to the first virtual resource. Further, based on the updated attribute state value, a resource destruction function in the smart contract can be invoked, and the second virtual resource can be destroyed within the blockchain. As can be seen above, this embodiment provides a blockchain-based resource fusion method. This method allows the fusion of the second attribute state value corresponding to the second virtual resource into the first attribute state value corresponding to the first virtual resource, thus achieving the fusion of the second virtual resource into the first virtual resource without the need to issue new virtual resources. Clearly, by updating attribute status values ​​and destroying the second virtual resource in this application, not only can the resource integration process be simplified on the blockchain, but the waste of blockchain storage space can also be reduced.

[0125] Further, please see Figure 11 , Figure 11 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application. The aforementioned blockchain-based data processing device 1 can be used to execute the corresponding steps in the method provided in the embodiments of this application. Figure 11 As shown, the blockchain-based data processing device 1 may include: a request acquisition module 11, a first determination module 12, a state fusion module 13, and a resource destruction module 14.

[0126] Request acquisition module 11 is used to acquire resource fusion request and acquire first certificate identifier and second certificate identifier based on resource fusion request; The first determining module 12 is used to call the resource fusion function in the smart contract according to the resource fusion request, and based on the resource fusion function, determine the resource fusion permission between the first virtual resource represented by the first warrant identifier and the second virtual resource represented by the second warrant identifier in the blockchain. The state fusion module 13 is used to merge the second attribute state value corresponding to the second virtual resource into the first attribute state value corresponding to the first virtual resource if the resource fusion permission is the resource fusion allowed permission and the first virtual resource is the fused virtual resource, so as to obtain the updated attribute state value corresponding to the first virtual resource. The resource destruction module 14 is used to call the resource destruction function in the smart contract according to the updated attribute status value, and destroy the second virtual resource in the blockchain based on the resource destruction function.

[0127] The specific functional implementations of the request acquisition module 11, the first determination module 12, the state fusion module 13, and the resource destruction module 14 can be found above. Figure 2 Steps S101-S104 in the corresponding embodiment will not be described again here.

[0128] Please see again Figure 11 The first determining module 12 may include a first determining unit 121 and a second determining unit 122.

[0129] The first determining unit 121 is used to determine, based on the resource fusion function, the first metadata corresponding to the first virtual resource represented by the first warrant identifier and the second metadata corresponding to the second virtual resource represented by the second warrant identifier in the blockchain. The first determining unit 121 is further configured to determine the first object identifier corresponding to the first virtual resource and the second object identifier corresponding to the second virtual resource; The second determining unit 122 is used to determine the resource fusion permission between the first virtual resource and the second virtual resource based on the first metadata, the second metadata, the first object identifier and the second object identifier.

[0130] The specific functional implementation methods of the first determining unit 121 and the second determining unit 122 can be found in the above description. Figure 2 Step S102 in the corresponding embodiment will not be described again here.

[0131] Please see again Figure 11 The resource fusion request also includes a fusion request identifier; The second determining unit 122 may include: a first determining subunit 1221 and a second determining subunit 1222.

[0132] The first determining subunit 1221 is used to determine the resource fusion permission between the first virtual resource and the second virtual resource as a resource fusion rejection permission if the fusion request identifier is different from at least one of the first object identifier or the second object identifier. The second determining subunit 1222 is used to determine the resource fusion permission based on the first metadata and the second metadata if the fusion request identifier is the same as the first object identifier and the second object identifier.

[0133] The specific functional implementation methods of the first determining subunit 1221 and the second determining subunit 1222 can be found in the above description. Figure 2 Step S102 in the corresponding embodiment will not be described again here.

[0134] Please see again Figure 11 The second determining subunit 1222 may include: a type comparison subunit 12221 and an authorization determining subunit 12222.

[0135] The type comparison subunit 12221 is used to obtain the first resource type in the first metadata and the second resource type in the second metadata, and compare the first resource type and the second resource type. The permission determination subunit 12222 is used to determine the resource fusion permission as the resource fusion denial permission if the first resource type is the same as the second resource type. The permission determination subunit 12222 is also used to determine resource fusion permissions based on the attribute status values ​​in the first metadata and the attribute status values ​​in the second metadata if the first resource type is different from the second resource type.

[0136] The specific implementation methods of the type comparison subunit 12221 and the permission determination subunit 12222 can be found above. Figure 2 Step S102 in the corresponding embodiment will not be described again here.

[0137] Please see again Figure 11 The second determining subunit 1222 may further include: resource determining subunit 12223.

[0138] The resource determination subunit 12223 is used to determine the first virtual resource as the virtual resource to be merged and the second virtual resource as the virtual resource to be merged if the resource fusion permission is the resource fusion allow permission, the first resource type is the type of resource to be merged, and the second resource type is the type of resource to be merged.

[0139] The specific functional implementation of the resource determination subunit 12223 can be found above. Figure 2 Step S102 in the corresponding embodiment will not be described again here.

[0140] Please see again Figure 11 The attribute status values ​​in the first metadata include the fusion threshold and the first fusion history value; the attribute status values ​​in the second metadata include the attribute fusion consumption value. The permission determination subunit 12222 is specifically used to determine the remaining value of the first virtual resource to be merged based on the merging threshold and the first merging historical value; The permission determination subunit 12222 is also specifically used to compare the remaining value to be merged with the attribute fusion consumption value. If the remaining value to be merged is less than the attribute fusion consumption value, the resource fusion permission is determined to be the resource fusion rejection permission. The permission determination subunit 12222 is also specifically used to determine the resource fusion permission as the resource fusion allowed permission if the remaining value to be merged is equal to or greater than the attribute fusion consumption value.

[0141] The specific implementation of the permission determination subunit 12222 can be found above. Figure 2 Step S102 in the corresponding embodiment will not be described again here.

[0142] Please see again Figure 11 The first attribute status value includes the first merged historical value and the first current business attribute value; the second attribute status value includes the attribute fusion consumption value and the business attribute value to be merged. The state fusion module 13 may include: a first adding unit 131, a second adding unit 132, and a third determining unit 133.

[0143] The first addition unit 131 is used to add the attribute fusion consumption value to the first fused history value to obtain the updated fused history value; The second adding unit 132 is used to add the business attribute value to be merged to the first current business attribute value to obtain the updated business attribute value; The third determining unit 133 is used to determine the updated merged historical value and the updated business attribute value as the updated attribute status value.

[0144] The specific functional implementation methods of the first adding unit 131, the second adding unit 132, and the third determining unit 133 can be found above. Figure 2 Step S103 in the corresponding embodiment will not be described again here.

[0145] Please see again Figure 11The second adding unit 132 may include: a third determining subunit 1321, a first adding subunit 1322, and a second adding subunit 1323.

[0146] The third determining subunit 1321 is used to determine the business attribute represented by the first current business attribute value and the business attribute represented by the business attribute value to be merged. The first adding subunit 1322 is used to add the business attribute value to be merged to the first business attribute value if the business attribute represented by the first current business attribute value includes the business attribute represented by the business attribute value to be merged, thereby obtaining an updated business attribute value; the business attribute represented by the first business attribute value is the same as the business attribute represented by the business attribute value to be merged; the first business attribute value belongs to the first current business attribute value; The second adding subunit 1323 is used to create a second business attribute value if the business attribute represented by the first current business attribute value does not include the business attribute represented by the business attribute value to be merged; the business attribute represented by the second business attribute value is the same as the business attribute represented by the business attribute value to be merged. The second adding subunit 1323 is also used to add the business attribute value to be merged to the second business attribute value, and add the second business attribute value with the business attribute value to be merged to the first current business attribute value to obtain the updated business attribute value.

[0147] The specific functional implementation methods of the third determining subunit 1321, the first adding subunit 1322, and the second adding subunit 1323 can be found above. Figure 2 Step S103 in the corresponding embodiment will not be described again here.

[0148] Please see again Figure 11 The first added subunit 1322 may include: attribute added subunit 13221 and attribute random subunit 13222.

[0149] The attribute addition sub-unit 13221 is used to add the business attribute value to be merged to the first business attribute value to obtain the intermediate business attribute value. The attribute random subunit 13222 is used to obtain a random number. The random number is used to randomly process the intermediate business attribute value to obtain the updated business attribute value.

[0150] The specific implementation methods of the attribute addition subunit 13221 and the attribute randomization subunit 13222 can be found above. Figure 2 Step S103 in the corresponding embodiment will not be described again here.

[0151] Please see again Figure 11 The second virtual resource has a fusion duration threshold; The blockchain-based data processing device 1 may further include: a second determination module 15 and a duration comparison module 16.

[0152] The second determining module 15 is used to determine the fusion time of the second attribute state value fused into the first attribute state value; The duration comparison module 16 is used to compare the fusion duration with the fusion duration threshold. If the fusion duration is equal to the fusion duration threshold, the second attribute status value is deleted from the third attribute status value corresponding to the first virtual resource to obtain the fourth attribute status value corresponding to the first virtual resource. The third attribute status value refers to the current attribute status value corresponding to the first virtual resource when the fusion duration is equal to the fusion duration threshold.

[0153] The specific functional implementation methods of the second determination module 15 and the duration comparison module 16 can be found in the above description. Figure 8 Steps S205-S206 in the corresponding embodiment will not be described again here.

[0154] Please see again Figure 11 The second attribute status value includes the attribute fusion consumption value and the business attribute value to be fused; the third attribute status value includes the second fused historical value and the second current business attribute value. The duration comparison module 16 may include: a first deletion unit 161, a second deletion unit 162, and a fourth determination unit 163.

[0155] The first deletion unit 161 is used to delete the attribute fusion consumption value from the second fused history value to obtain the third fused history value; The second deletion unit 162 is used to delete the business attribute value to be merged from the second current business attribute value to obtain the third current business attribute value. The fourth determining unit 163 is used to determine the third merged historical value and the third current business attribute value as the fourth attribute status value corresponding to the first virtual resource.

[0156] The specific functional implementation methods of the first deletion unit 161, the second deletion unit 162, and the fourth determination unit 163 can be found above. Figure 8 Step S206 in the corresponding embodiment will not be described again here.

[0157] Please see again Figure 11 The blockchain-based data processing device 1 may also include: a third determination module 17 and a resource issuance module 18.

[0158] The request acquisition module 11 is also used to acquire a resource issuance request; the resource issuance request includes resource details information, which includes the issuance object identifier, the target virtual resource, the resource type corresponding to the target virtual resource, and the fifth attribute status value corresponding to the target virtual resource; the target virtual resource is a first virtual resource or a second virtual resource; The third determining module 17 is used to determine the resource issuance authority of the target virtual resource based on the resource type corresponding to the target virtual resource and the status value of the fifth attribute. The third determination module 17 is also used to determine the target certificate identifier corresponding to the target virtual resource based on the resource details information when the resource issuance permission is the resource issuance permission. Resource issuance module 18 is used to execute the resource issuance function in the smart contract based on the resource details and the target warrant identifier; The resource issuance module 18 is also used to issue the target virtual resource to the issuance object identifier based on the resource issuance function.

[0159] The specific functional implementation methods of the request acquisition module 11, the third determination module 17, and the resource issuance module 18 can be found in the above description. Figure 10 Steps S301-S305 in the corresponding embodiment will not be described again here.

[0160] Please see again Figure 11 The third determining module 17 may include a fifth determining unit 171 and a sixth determining unit 172.

[0161] The fifth determining unit 171 is used to determine the resource issuance permission as the resource issuance permission if the resource type corresponding to the target virtual resource is a fused resource type and the fifth attribute status value includes the attribute fusion consumption value and the business attribute value to be fused. The sixth determining unit 172 is used to determine the resource issuance permission as the resource issuance permission if the resource type corresponding to the target virtual resource is the type of resource to be merged, and the fifth attribute status value includes the merging threshold, the initial merging historical value and the initial business attribute value.

[0162] The specific functional implementation methods of the fifth determining unit 171 and the sixth determining unit 172 can be found in the above description. Figure 10 Step S302 in the corresponding embodiment will not be described again here.

[0163] In this embodiment, upon receiving a resource fusion request including a first warrant identifier and a second warrant identifier, a blockchain node can invoke a resource fusion function in a smart contract based on the request. Based on this function, the resource fusion permission between the first virtual resource represented by the first warrant identifier and the second virtual resource represented by the second warrant identifier can be determined within the blockchain. Furthermore, if the resource fusion permission is a resource fusion allowed permission and the first virtual resource is the fused virtual resource, the second attribute state value corresponding to the second virtual resource can be merged into the first attribute state value corresponding to the first virtual resource to obtain an updated attribute state value corresponding to the first virtual resource. Further, based on the updated attribute state value, a resource destruction function in the smart contract can be invoked, and the second virtual resource can be destroyed within the blockchain. As can be seen above, this embodiment provides a blockchain-based resource fusion method. This method allows the fusion of the second attribute state value corresponding to the second virtual resource into the first attribute state value corresponding to the first virtual resource, thus achieving the fusion of the second virtual resource into the first virtual resource without the need to issue new virtual resources. Clearly, by updating attribute status values ​​and destroying the second virtual resource in this application, not only can the resource integration process be simplified on the blockchain, but the waste of blockchain storage space can also be reduced.

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

[0165] exist Figure 12In the computer device 1000 shown, the network interface 1004 provides network communication functionality; 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 achieve: Obtain a resource fusion request, and obtain the first certificate identifier and the second certificate identifier based on the resource fusion request; Based on the resource fusion request, the resource fusion function in the smart contract is invoked. Based on the resource fusion function, the resource fusion permission between the first virtual resource represented by the first warrant identifier and the second virtual resource represented by the second warrant identifier is determined in the blockchain. If the resource fusion permission is the resource fusion allowed permission and the first virtual resource is the virtual resource to be fused, then the second attribute status value corresponding to the second virtual resource is merged into the first attribute status value corresponding to the first virtual resource to obtain the updated attribute status value corresponding to the first virtual resource. The resource destruction function in the smart contract is called based on the updated attribute state value. Based on the resource destruction function, the second virtual resource is destroyed in the blockchain.

[0166] It should be understood that the computer device 1000 described in the embodiments of this application can perform the data processing methods or apparatus based on blockchain described in the preceding embodiments, and will not be repeated here. In addition, the beneficial effects of using the same method will also not be repeated.

[0167] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the blockchain-based data processing methods or apparatus described in the preceding embodiments, which will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0168] The aforementioned computer-readable storage medium can be the internal storage unit of the blockchain-based data processing apparatus provided in any of the foregoing embodiments, or the computer device, such as the hard drive 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 drive, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal and external storage units 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 will be output.

[0169] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, enabling the computer device to perform the blockchain-based data processing methods or apparatus described in the preceding embodiments, which will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

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

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

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

Claims

1. A data processing method based on blockchain, characterized in that, include: Obtain a resource fusion request, and obtain a first certificate identifier and a second certificate identifier based on the resource fusion request; The resource fusion request includes a fusion request identifier; According to the resource fusion request, the resource fusion function in the smart contract is invoked. Based on the resource fusion function, the first metadata of the first virtual resource represented by the first warrant identifier and the second metadata of the second virtual resource represented by the second warrant identifier are determined in the blockchain. The first metadata includes a first resource type. The second metadata includes a second resource type. The attribute status values ​​in the first metadata include the fusion threshold and the first fusion history value; the attribute status values ​​in the second metadata include the attribute fusion consumption value. Determine the first object identifier that holds the first virtual resource and the second object identifier that holds the second virtual resource; If the fusion request identifier is the same as the first object identifier and the second object identifier, then the first resource type and the second resource type are compared. If the first resource type is different from the second resource type, then the remaining value of the first virtual resource to be merged is determined based on the merging threshold and the first merging historical value. The remaining value to be merged is compared with the attribute fusion consumption value. If the remaining value to be merged is less than the attribute fusion consumption value, then the resource fusion permission between the first virtual resource and the second virtual resource is determined to be a resource fusion denial permission. If the remaining value to be merged is equal to or greater than the attribute fusion consumption value, then the resource fusion permission is determined to be the resource fusion permitted permission; If the resource fusion permission is the resource fusion allow permission and the first virtual resource is the virtual resource to be fused, then the second attribute status value corresponding to the second virtual resource is fused into the first attribute status value corresponding to the first virtual resource to obtain the updated attribute status value corresponding to the first virtual resource. The resource destruction function in the smart contract is invoked based on the updated attribute status value, and the second virtual resource is destroyed in the blockchain based on the resource destruction function.

2. The method according to claim 1, characterized in that, The method further includes: If the fusion request identifier is different from at least one of the first object identifier or the second object identifier, then the resource fusion permission between the first virtual resource and the second virtual resource is determined to be a resource fusion rejection permission.

3. The method according to claim 1, characterized in that, The method further includes: If the first resource type is the same as the second resource type, then the resource fusion permission is determined to be the resource fusion rejection permission.

4. The method according to claim 1, characterized in that, The method further includes: If the resource fusion permission is the resource fusion allow permission, and the first resource type is the type of resource to be fused, and the second resource type is the type of fused resource, then the first virtual resource is determined to be the virtual resource to be fused, and the second virtual resource is the fused virtual resource.

5. The method according to claim 1, characterized in that, The first attribute status value includes a first current business attribute value, and the second attribute status value includes a business attribute value to be merged; The step of fusing the second attribute status value corresponding to the second virtual resource into the first attribute status value corresponding to the first virtual resource to obtain the updated attribute status value corresponding to the first virtual resource includes: Add the attribute fusion consumption value to the first fused history value to obtain the updated fused history value; The value of the service attribute to be merged is added to the first current service attribute value to obtain the updated service attribute value; The update merged historical value and the update business attribute value are determined as the update attribute status value.

6. The method according to claim 5, characterized in that, The step of adding the service attribute value to be merged to the first current service attribute value to obtain the updated service attribute value includes: Determine the business attribute represented by the first current business attribute value, and the business attribute represented by the business attribute value to be merged; If the business attribute represented by the first current business attribute value includes the business attribute represented by the business attribute value to be merged, then the business attribute value to be merged is added to the first business attribute value to obtain an updated business attribute value; the business attribute represented by the first business attribute value is the same as the business attribute represented by the business attribute value to be merged; the first business attribute value belongs to the first current business attribute value. If the business attributes represented by the first current business attribute value do not include the business attributes represented by the business attribute value to be merged, then a second business attribute value is created; the business attributes represented by the second business attribute value are the same as the business attributes represented by the business attribute value to be merged. The business attribute value to be merged is added to the second business attribute value, and the second business attribute value with the added business attribute value is added to the first current business attribute value to obtain the updated business attribute value.

7. The method according to claim 6, characterized in that, The step of adding the business attribute value to be merged to the first business attribute value to obtain the updated business attribute value includes: The business attribute value to be merged is added to the first business attribute value to obtain the intermediate business attribute value; Obtain a random number, and then use the random number to randomly process the intermediate business attribute value to obtain an updated business attribute value.

8. The method according to claim 1, characterized in that, The second virtual resource has a fusion duration threshold; The method further includes: Determine the fusion time for the second attribute state value to be fused into the first attribute state value; The fusion duration is compared with the fusion duration threshold. If the fusion duration is equal to the fusion duration threshold, the second attribute status value is deleted from the third attribute status value corresponding to the first virtual resource to obtain the fourth attribute status value corresponding to the first virtual resource. The third attribute status value refers to the current attribute status value corresponding to the first virtual resource when the fusion duration is equal to the fusion duration threshold.

9. The method according to claim 8, characterized in that, The second attribute status value includes the attribute value of the service to be merged; the third attribute status value includes the second merged historical value and the second current service attribute value. The step of deleting the second attribute status value from the third attribute status value corresponding to the first virtual resource to obtain the fourth attribute status value corresponding to the first virtual resource includes: The attribute fusion consumption value is removed from the second fused history value to obtain the third fused history value; The business attribute value to be merged is deleted from the second current business attribute value to obtain the third current business attribute value; The third merged historical value and the third current business attribute value are determined as the fourth attribute status value corresponding to the first virtual resource.

10. The method according to claim 1, characterized in that, The method further includes: Obtain a resource issuance request; the resource issuance request includes resource details, which include an issuance target identifier, a target virtual resource, a resource type corresponding to the target virtual resource, and a fifth attribute status value corresponding to the target virtual resource; the target virtual resource is either the first virtual resource or the second virtual resource. Based on the resource type corresponding to the target virtual resource and the fifth attribute status value, determine the resource issuance authority of the target virtual resource; When the resource issuance permission is the resource issuance permitted permission, the target certificate identifier corresponding to the target virtual resource is determined based on the resource details information; Based on the resource details and the target warrant identifier, the resource issuance function in the smart contract is executed; Based on the resource issuance function, the target virtual resource is issued to the issuance object identifier.

11. The method according to claim 10, characterized in that, The step of determining the resource issuance permission of the target virtual resource based on the resource type corresponding to the target virtual resource and the fifth attribute status value includes: If the resource type corresponding to the target virtual resource is a fused resource type, and the fifth attribute status value includes the attribute fusion consumption value and the attribute value of the business to be fused, then the resource issuance permission is determined to be the resource issuance permission. If the resource type corresponding to the target virtual resource is the type of resource to be merged, and the fifth attribute status value includes the merging threshold, the initial merging history value, and the initial business attribute value, then the resource issuance permission is determined to be the resource issuance permission.

12. A data processing device based on blockchain, characterized in that, include: The request retrieval module is used to retrieve resource fusion requests; The resource fusion request includes a first certificate identifier and a second certificate identifier; The resource fusion request includes a fusion request identifier; The first determining module is configured to, according to the resource fusion request, invoke a resource fusion function in a smart contract, and based on the resource fusion function, determine, in the blockchain, the first metadata of the first virtual resource represented by the first warrant identifier and the second metadata of the second virtual resource represented by the second warrant identifier; the first metadata includes a first resource type; the second metadata includes a second resource type; The attribute status values ​​in the first metadata include the fusion threshold and the first fusion history value; the attribute status values ​​in the second metadata include the attribute fusion consumption value. The first determining module is further configured to determine a first object identifier holding the first virtual resource and a second object identifier holding the second virtual resource; The first determining module is further configured to compare the first resource type and the second resource type if the fusion request identifier is the same as the first object identifier and the second object identifier; The first determining module is further configured to determine the remaining value of the first virtual resource to be merged based on the merging threshold and the first merging historical value if the first resource type is different from the second resource type; The first determining module is further configured to compare the remaining value to be merged with the attribute fusion consumption value; if the remaining value to be merged is less than the attribute fusion consumption value, then the resource fusion permission between the first virtual resource and the second virtual resource is determined to be a resource fusion rejection permission. The first determining module is further configured to determine the resource fusion permission as the resource fusion allowed permission if the remaining value to be fused is equal to or greater than the attribute fusion consumption value; The status fusion module is used to merge the second attribute status value corresponding to the second virtual resource into the first attribute status value corresponding to the first virtual resource if the resource fusion permission is the resource fusion permission and the first virtual resource is the virtual resource to be fused, so as to obtain the updated attribute status value corresponding to the first virtual resource. The resource destruction module is used to call the resource destruction function in the smart contract according to the updated attribute status value, and destroy the second virtual resource in the blockchain based on the resource destruction function.

13. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store computer programs, and the processor is used to invoke the computer programs to cause the computer device to perform the method according to any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-11.

15. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium, the computer program being adapted to be read and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-11.

Images