Virtual asset processing method and apparatus in a blockchain, device, and medium

Abstract

Embodiments of the present application provide a virtual asset processing method and device in a blockchain, equipment and medium. The method comprises: receiving an asset collection request sent by a request device, calling an asset transfer contract in the blockchain based on a random factor carried by the asset collection request; calling a random verifiable contract in the blockchain through the asset transfer contract, generating an asset transfer random number based on the random factor and a random number stored in the random verifiable contract, generating a private key; determining a target virtual asset corresponding to the asset transfer random number through the asset transfer contract, returning the target virtual asset and the asset transfer random number to the request device, so that the request device verifies the validity of the target virtual asset based on the random factor, the asset transfer random number and a random number verification public key. The embodiments of the present application can guarantee the randomness of virtual asset distribution and improve the verifiability of random distribution of virtual assets.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a method, apparatus, device, and medium for processing virtual assets in a blockchain. Background Technology

[0002] In current blockchain virtual asset scenarios, after an asset issuer publishes virtual assets on the blockchain, the random collection rules for these virtual assets can be published in a smart contract. Typically, an object can call the smart contract in the blockchain to collect the virtual assets published by the asset issuer. When the object initiates a transaction to collect virtual assets on the blockchain, the specific virtual assets it collects have already been determined. Therefore, the process of an object collecting virtual resources on the blockchain does not have randomness. The object can control the specific virtual resources collected by continuously initiating transactions, thus causing fraud in the virtual resource distribution process. Summary of the Invention

[0003] This application provides a method, apparatus, device, and medium for processing virtual assets in a blockchain, which can ensure the randomness of virtual asset issuance and improve the verifiability of random virtual asset issuance.

[0004] This application provides a method for processing virtual assets in a blockchain, including:

[0005] Receive the asset retrieval request sent by the requesting device, and invoke the asset transfer contract in the blockchain based on the random factor carried in the asset retrieval request;

[0006] By calling a random verifiable contract in the blockchain through an asset transfer contract, a private key is generated based on a random factor and the random number stored in the random verifiable contract, and a random number for asset transfer is generated.

[0007] The target virtual asset corresponding to the asset transfer random number is determined through the asset transfer contract. The target virtual asset and the asset transfer random number are returned to the requesting device so that the requesting device can verify the validity of the target virtual asset based on the random factor, the asset transfer random number and the random number verification public key.

[0008] This application provides a method for processing virtual assets in a blockchain, including:

[0009] A request to claim an asset carrying a random factor is sent to a blockchain node, so that the blockchain node calls the asset transfer contract in the blockchain based on the random factor. The asset transfer contract determines the target virtual asset corresponding to the random number of the asset transfer. The random number of the asset transfer is generated based on the random factor and the random number generation private key stored in the random verifiable contract. The random verifiable contract is called by the asset transfer contract.

[0010] The system receives the target virtual asset and asset transfer random number returned by the blockchain node. It obtains the random verification result of the asset transfer random number by using the random factor, the asset transfer random number, and the random number verification public key. When the random verification result indicates that the verification is successful, the target virtual asset is determined to be valid.

[0011] This application provides, in one aspect, a virtual asset processing device in a blockchain, comprising:

[0012] The contract invocation module is used to receive asset retrieval requests sent by the requesting device and, based on the random factor carried in the asset retrieval request, invoke the asset transfer contract in the blockchain.

[0013] The random number generation module is used to call the random verifiable contract in the blockchain through the asset transfer contract, generate a private key based on the random factor and the random number stored in the random verifiable contract, and generate random numbers for asset transfer.

[0014] The virtual asset determination module is used to determine the target virtual asset corresponding to the asset transfer random number through the asset transfer contract, and return the target virtual asset and the asset transfer random number to the requesting device so that the requesting device can verify the validity of the target virtual asset based on the random factor, the asset transfer random number and the random number verification public key.

[0015] The contract invocation module includes:

[0016] The validity verification unit is used to receive the asset retrieval request sent by the requesting device, verify the validity of the asset retrieval request, and obtain the request verification result corresponding to the asset retrieval request.

[0017] The asset transfer contract invocation unit is used to obtain the random factor carried in the asset retrieval request when the request verification result indicates successful verification, and invoke the asset transfer contract in the blockchain based on the random factor.

[0018] The validity verification unit includes:

[0019] The signature acquisition subunit is used to acquire the digital signature carried in the asset retrieval request, as well as the public key of the object corresponding to the requesting device;

[0020] The hash operation subunit is used to decrypt the digital signature based on the object's public key to obtain the first digest information corresponding to the digital signature, and to perform a hash operation on the asset redemption request based on the hash algorithm to obtain the second digest information corresponding to the asset redemption request.

[0021] The verification passed sub-unit is used to determine the verification result of the asset retrieval request as a verification passed result if the first summary information is the same as the second summary information.

[0022] The random number generation module includes:

[0023] The asset retrieval authority determination unit is used to obtain the object information carried in the asset retrieval request. When the object information meets the asset retrieval conditions indicated by the asset transfer contract, it determines that the target object associated with the requesting device has asset retrieval authority.

[0024] The Random Verifiable Contract Invocation Unit is used to pass a random factor into a random verifiable contract in the blockchain through an asset transfer contract, and execute the random verifiable contract based on the random factor.

[0025] The random number generation module also includes:

[0026] The random number generation service invocation unit is used to obtain the random number generation private key stored in the random verifiable contract, and invoke the random number generation service through the random factor in the random verifiable contract; the random number generation service is not part of the blockchain;

[0027] The asset transfer random number generation unit is used to perform calculations on the random number generation private key and random factor based on the verifiable random function in the random number generation service to obtain the asset transfer random number.

[0028] The virtual asset identification module includes:

[0029] The asset quantity acquisition unit is used to acquire a virtual asset set in the asset transfer contract and to acquire the asset quantity of the virtual assets contained in the virtual asset set.

[0030] The virtual asset transfer unit is used to execute the transfer business logic in the asset transfer contract. Based on the asset transfer random number and the asset quantity, it obtains the target virtual asset for transfer and transfers the target virtual asset in the virtual asset set to the object account corresponding to the requesting device.

[0031] Specifically, the virtual asset transfer unit is used for:

[0032] Execute the transfer business logic in the asset transfer contract, and perform a remainder operation on the asset quantity using the asset transfer random number to obtain the first virtual asset;

[0033] If the first virtual asset does not belong to the virtual asset set, then the second virtual asset is obtained by taking the remainder of the asset quantity using the first virtual asset.

[0034] If the second virtual asset belongs to the collection of virtual assets, then the first virtual asset is identified as the target virtual asset for transfer.

[0035] This application provides, in one aspect, a virtual asset processing device in a blockchain, comprising:

[0036] The sending module is used to send an asset claim request carrying a random factor to the blockchain node, so that the blockchain node can call the asset transfer contract in the blockchain based on the random factor, and determine the target virtual asset corresponding to the random number of asset transfer through the asset transfer contract; the random number of asset transfer is generated based on the random factor and the random number generation private key stored in the random verifiable contract, which is called by the asset transfer contract;

[0037] The receiving module is used to receive the target virtual asset and asset transfer random number returned by the blockchain node. It obtains the random verification result of the asset transfer random number by using the random factor, the asset transfer random number and the random number verification public key. When the random verification result indicates that the verification is successful, the target virtual asset is determined to be valid.

[0038] The device also includes:

[0039] The audit request sending module is used to determine that the target virtual asset is not valid when the random verification result indicates that the verification has failed. It then sends an asset transfer audit request to the blockchain node so that the blockchain node can reallocate the target virtual asset for the requesting device to transfer.

[0040] The device also includes:

[0041] The authentication information verification module is used to receive the object registration request corresponding to the target object, obtain the object authentication information carried in the object registration request, verify the object authentication information through the object management interface, and obtain the identity authentication result corresponding to the object authentication information.

[0042] The permission determination module is used to determine whether the target object has the permission to initiate an asset retrieval request when the identity authentication result indicates successful authentication.

[0043] The device also includes:

[0044] The random factor generation module is used to obtain the generation timestamp corresponding to the asset claim request, obtain the random factor based on the generation timestamp, and add the random factor to the asset claim request.

[0045] One aspect of this application provides a computer device, including a memory and a processor. The memory is connected to the processor, 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 method provided in one aspect of this application.

[0046] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having a processor performs the method provided in one aspect of this application.

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

[0048] In this embodiment, by deploying an asset transfer contract and a random verifiable contract in the blockchain, upon receiving an asset claim request from a requesting device, the asset transfer contract in the blockchain can be invoked based on the random factor carried in the asset claim request. This asset transfer contract can then invoke the random verifiable contract in the blockchain, and a private key (corresponding to the random verifiable contract) is generated based on the random factor and random number uploaded by the requesting device, thus generating a verifiable asset transfer random number. The asset transfer contract can determine the target virtual asset corresponding to the asset transfer random number. This target virtual asset and the asset transfer random number can be returned to the requesting device. The requesting device can verify the validity of the target virtual asset based on the random factor, the asset transfer random number, and the random number verification public key. In other words, by introducing a random verifiable contract and generating verifiable asset transfer random numbers under the blockchain, the randomness of virtual asset issuance can be guaranteed by verifying the correctness of the asset transfer random number, and the verifiability of virtual asset issuance can be improved. Attached Figure Description

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

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

[0051] Figure 2 This is a schematic diagram illustrating the deployment of a blockchain smart contract provided in an embodiment of this application;

[0052] Figure 3 This is a flowchart illustrating a method for processing virtual assets in a blockchain, as provided in an embodiment of this application.

[0053] Figure 4 This is a schematic diagram of transaction synchronization in a blockchain network provided in an embodiment of this application;

[0054] Figure 5 This is a schematic diagram illustrating the random distribution of virtual assets on a blockchain, provided in an embodiment of this application.

[0055] Figure 6 This is a timing diagram illustrating a method for processing virtual assets in a blockchain, as provided in an embodiment of this application.

[0056] Figure 7 This is a schematic diagram of an object registration scenario provided in an embodiment of this application;

[0057] Figure 8 This is a flowchart illustrating a method for issuing virtual assets in a blockchain, as provided in an embodiment of this application.

[0058] Figure 9 This is a schematic diagram of the structure of a virtual asset processing device in a blockchain provided in an embodiment of this application;

[0059] Figure 10 This is a schematic diagram of another virtual asset processing device in a blockchain provided in this application embodiment;

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

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

[0062] This application relates to blockchain technology. Blockchain is a decentralized infrastructure with distributed storage characteristics. Specifically, it is a data structure that organizes data blocks in chronological order using a linked list-like manner. It can securely store data with sequential relationships that can be verified within the system, and uses cryptography to ensure that the data is immutable and unforgeable.

[0063] The underlying blockchain platform can include modules for basic services, smart contracts, and operations management. The basic service module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic service first performs interface adaptation parsing and authentication (interface adaptation), then encrypts the business information using a consensus algorithm (consensus management), and transmits it completely and consistently to the shared ledger (network communication) for recording and storage. The smart contract module is responsible for contract registration, publication, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). Based on the contract terms, execution is triggered by calling keys or other events to complete the contract logic. It also provides functions for contract upgrades and cancellations. The operations management module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization during product launch, such as alarms, network status management, and node device health status management.

[0064] Smart contracts can be understood as computer programs running on a distributed ledger (i.e., blockchain) with pre-defined rules, states, and conditional responses. They encapsulate, verify, and execute complex behaviors of distributed nodes to complete information exchange, value transfer, and asset management. Based on the distributed architecture and consensus algorithms of blockchain, smart contracts allow users who do not trust each other to complete transactions without any trusted third-party intermediaries or authorities. Furthermore, digital smart contracts can be flexibly embedded in various tangible or intangible assets, transactions, and data to achieve active or passive asset and information management and control, gradually building programmable smart assets and systems.

[0065] Please see Figure 1 , Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application. The network architecture may include an electronic device 10a and a blockchain network. The electronic device 10a may refer to a device outside the blockchain network. The blockchain network may consist of multiple blockchain nodes, and this application does not limit the number of blockchain nodes included in the blockchain network. Figure 1 Taking six blockchain nodes as an example, the blockchain nodes in the network are networked in a P2P (Peer-to-Peer) manner, and the blockchain nodes can communicate with each other according to the P2P protocol. All blockchain nodes in the network jointly follow the broadcast mechanism and consensus mechanism to ensure the immutability and forgery resistance of data on the blockchain, while realizing the decentralized and trustless characteristics of the blockchain.

[0066] In this application, the electronic device 10a and the blockchain node in the blockchain network can be a user terminal, a server, or a system composed of a user terminal and a server; this application does not limit the specific type of device. The user terminal can include, but is not limited to: PC (Personal Computer), smartphone, tablet computer, laptop computer, PDA, mobile internet device (MID), wearable device (e.g., smartwatch, smart bracelet), smart voice interaction device, smart home appliance (e.g., smart TV), in-vehicle device, etc.

[0067] A server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0068] A blockchain, maintained jointly by blockchain nodes in a blockchain network, can consist of a series of blocks, also known as data blocks. After a block is created, consensus processing must be performed within the blockchain network. Only after successful consensus is reached can the block be added to the blockchain. Blocks in a blockchain can be linked together in ascending order of their creation timestamps to form a chain structure. A blockchain is a distributed ledger, and the information data contained within each block of the blockchain constitutes the ledger data of that distributed ledger.

[0069] It is understood that the managed object can use electronic device 10a to deploy asset transfer contracts and random verifiable contracts on the blockchain. The managed object can have the authority to register users and issue virtual assets; this managed object can also be called the contract deployment object. The asset transfer contract can be used to publish the virtual assets issued by the asset issuer, as well as the conditions and rules for randomly receiving virtual assets on the chain. The asset issuer can be considered as an enterprise, institution, or user that issues virtual assets on the blockchain, and can manage and transfer the virtual assets issued to their own account. These virtual assets can include asset certificates (e.g., certificates of assets held by users on the blockchain), game currency, etc. This application does not restrict the type of virtual assets.

[0070] A random verifiable contract can be used to store the private key of a random number generation algorithm (which can be called the random number generation private key). This random verifiable contract can call random number generation services outside the blockchain (i.e., off-chain) and generate verifiable random numbers based on these services. These random numbers can be called asset transfer random numbers. The random verifiable random number can be a VRF (Verifiable Random Function) contract; a VRF is an encryption scheme that maps input to a verifiable pseudo-random output. A VRF can output a verifiable asset transfer random number. Since this asset transfer random number can contain the signature of the random number generation private key, its legitimacy can be determined using the random number verification public key. The aforementioned random number generation private key and random number verification public key are the public-private key pair of the random number generation algorithm.

[0071] VRF possesses three main characteristics: verifiability, uniqueness, and randomness. Verifiability means that the VRF random number generation algorithm can be verified. The random numbers generated for asset transfers using a private key and a random factor (which can also be considered a random number) can be verified using the public key, the random factor, and the asset transfer random number. Uniqueness means that the result of the asset transfer random number generated by any random factor is deterministic; that is, for the same random factor, the asset transfer random number obtained through VRF will always be the same. Randomness means that the process of generating the asset transfer random number using the private key and random factor is completely random. Mathematical theorems guarantee that the random process cannot be cracked. For example, for different random factors, the asset transfer random numbers obtained through VRF are random and uniformly distributed within the value range.

[0072] Optionally, an ordinary user can use electronic device 10a to request virtual assets on the blockchain from a blockchain node. The user can generate a random factor locally and send an asset request carrying that random factor to the blockchain network to randomly claim virtual assets. The user can verify the correctness of the asset transfer random number using the returned asset transfer random number, random factor, and random number verification public key, thereby ensuring the authenticity of the random asset distribution process. The user can manage their own virtual assets and query detailed information about them. In this embodiment, by introducing VRF technology, it can be ensured that the virtual asset distribution process in the blockchain is random and verifiable.

[0073] Please see Figure 2 , Figure 2 This is a schematic diagram illustrating the deployment of a blockchain smart contract according to an embodiment of this application. Figure 2The user terminal 20a shown can be an electronic device used by the managed object (manager). The user terminal 20a can initialize a public-private key pair of a random number generation algorithm (e.g., VRF). The public-private key pair can include a random number generation private key and a random number verification public key. The random number verification public key can be made public to the object for verification of asset transfer random numbers. The random number generation private key can be stored in a randomly verifiable contract for generating asset transfer random numbers.

[0074] The managed entity can upload an asset transfer contract to the blockchain network via user terminal 20a in the form of a transaction. Upon receiving the transaction containing the asset transfer contract submitted by user terminal 20a, blockchain node 20b in the blockchain network can verify the transaction. The purpose of verification is to detect whether the transaction containing the asset transfer contract has been tampered with during transmission. If the verification fails, it indicates that the transaction may have been tampered with during upload by user terminal 20a, and it needs to be re-uploaded; if the verification passes, it indicates that the transaction containing the asset transfer contract has not been tampered with during transmission.

[0075] Blockchain node 20b can package the verified transaction containing the asset transfer contract into block X. The block header of block X (where X is a positive integer) contains the digest value corresponding to the block with the highest block height in the blockchain, such as the digest value of block X-1. It can also contain the digest value of the current block X and the Merkle root of the current block X. The block body of block X can contain the complete information data of the current block X, such as the asset transfer contract uploaded by user terminal 20a. Blockchain node 20b can broadcast the newly generated block X in the blockchain network, that is, send block X to all blockchain nodes participating in the consensus process in the blockchain network, so that the blockchain nodes participating in the consensus process can verify the consensus of block X. When block X passes the consensus, it can be added to the blockchain for formal on-chain, which means that the asset transfer contract has been successfully created in the blockchain.

[0076] Similarly, the managed object can upload a random verifiable contract to the blockchain network by initiating a transaction through user terminal 20a. After receiving the transaction containing the random verifiable contract submitted by user terminal 20a, blockchain node 20c in the blockchain network can perform the same operation as the aforementioned asset transfer contract, which will not be elaborated here. Blockchain node 20b and blockchain node 20c can be the same node in the blockchain network or different nodes; this application does not limit this. The aforementioned asset transfer contract and random verifiable contract can be uploaded to the blockchain network using different transactions. In this case, the asset transfer contract and the random verifiable contract can be packaged into the same block with different transactions, or they can be packaged into different blocks (e.g., block X containing the asset transfer contract, block X+1 containing the random verifiable contract). Alternatively, they can be uploaded to the blockchain network using the same transaction, in which case the asset transfer contract and the random verifiable contract can be packaged into the same block; this application does not limit this.

[0077] It should be noted that the aforementioned asset transfer contract and random verifiable contract can be computer program code. Developers can write these using high-level smart contract languages. A compiler can then compile these high-level language contracts into bytecode within the virtual machine of the blockchain node. The virtual machine can interpret and execute the bytecode in the smart contract. High-level smart contract languages ​​include, but are not limited to, Solidity (a smart contract programming language), Serpent (a smart contract programming language), and LLL (a smart contract programming language). For example, developers can use Solidity to write data contracts and business contracts, and use a compiler to compile these Solidity data contracts and business contracts into virtual machine bytecode. The compiled virtual machine bytecode is then submitted to the blockchain network along with the transaction initiated by user terminal 20a and uploaded to the chain.

[0078] like Figure 2As shown, assuming block X contains an asset transfer contract and block X+1 contains a random verifiable contract, after blocks X and X+1 are successfully added to the blockchain, the blockchain jointly maintained by the blockchain nodes in the blockchain network is as shown in blockchain 20d. Blocks X-1, X, and X+1 in blockchain 20d can be connected in sequence to form a chain structure. X-1, X, and X+1 can all be considered as the block height in the blockchain. The block height can be used to represent the number of blocks connected to the blockchain, and can be considered a block identifier, indicating the block's position in the blockchain. The default block height of the genesis block in the blockchain is 0. The block height of the first block after the genesis block is 1 (the first block can be called block 1), the block height of the second block after the genesis block is 2 (the second block can be called block 2), and so on. Each block in a blockchain can be divided into two parts: a block header and a block body. Of course, the complete transaction data in the block body can be organized together in the form of a Xerkle tree.

[0079] The information data in the block body can refer to the original data requested and published to the blockchain network. Xerkle trees are an important component of blockchain technology. Blockchains typically do not store plaintext original data; the original data needs to undergo hashing (also known as hash operation) and be stored as hash values. Merkle trees can be used to organize the hash values ​​generated from hashing multiple original data points into a binary tree structure and store them in the block body. The digest value of the current block and the digest value of the previous block, contained in the block header, can be called hash values.

[0080] Please see Figure 3 , Figure 3 This is a flowchart illustrating a method for processing virtual assets in a blockchain, as provided in an embodiment of this application. It is understood that this method can be executed by any blockchain node in the blockchain network. Figure 3 As shown, the virtual asset processing method in this blockchain may include at least the following steps S101-S103:

[0081] Step S101: Receive the asset retrieval request sent by the requesting device, and invoke the asset transfer contract in the blockchain based on the random factor carried in the asset retrieval request.

[0082] Specifically, when a user (hereinafter referred to as the target object for ease of description, which can be the aforementioned ordinary object) wants to claim virtual assets on the blockchain, they can generate a random factor locally through a requesting device and send an asset claim request carrying the random factor to a blockchain node in the blockchain network. The requesting device can encapsulate the asset claim request carrying the random factor into a transaction and submit it to the blockchain network in the form of a transaction.

[0083] Upon receiving a transaction submitted by a requesting device, a blockchain node in the blockchain network indicates that it has received the asset redemption request sent by the requesting device. After obtaining the transaction containing the asset redemption request, the blockchain node needs to synchronize the transaction across the blockchain network, such as by broadcasting the transaction containing the asset redemption request to the other nodes in the blockchain network. See also... Figure 4 , Figure 4 This is a schematic diagram illustrating transaction synchronization in a blockchain network according to an embodiment of this application. Figure 4 As shown, assuming the blockchain network includes blockchain nodes such as node 1, node 2, node 3, node 4, and node 5, each blockchain node can have a transaction pool, which can be used to temporarily cache transactions that have not yet been packaged into blocks.

[0084] When a requesting device encapsulates an asset redemption request carrying a random factor into a transaction tx1, it can submit transaction tx1 to node 1 in the blockchain network. After receiving the transaction tx1 submitted by the requesting device, node 1 can cache transaction tx1 in its own transaction pool for later packaging. At the same time, node 1 can broadcast transaction tx1 as a transaction message to the other blockchain nodes in the blockchain network, such as node 2, node 3, node 4, and node 5; after receiving transaction tx1, the other blockchain nodes can also put transaction tx1 from the transaction message into their own transaction pools.

[0085] It is understandable that transaction tx1 may be lost during transmission. To ensure that transaction tx1 reaches as many blockchain nodes as possible in the blockchain network, blockchain nodes that receive transaction tx1 via broadcast can select one or more adjacent blockchain nodes to relay the broadcast, based on their own network topology and network traffic strategy. This provides the basis for packaging transaction tx1 into a block during the consensus process.

[0086] Furthermore, blockchain nodes can package transactions in the transaction pool to generate new blocks. During the block consensus process, blockchain nodes can execute all transactions in the block, including those containing asset redemption requests. When a blockchain node executes a transaction containing an asset redemption request, it can obtain the random factor carried by the request and invoke the asset transfer contract within the blockchain based on this random factor. In other words, the random factor can be passed into the asset transfer contract within the blockchain, and the contract can be run within the virtual machine of the blockchain node.

[0087] Step S102: The asset transfer contract calls the random verifiable contract in the blockchain, generates a private key based on the random factor and the random number stored in the random verifiable contract, and generates a random number for asset transfer.

[0088] Specifically, when a blockchain node runs an asset transfer contract, the asset transfer contract can call a random verifiable contract in the blockchain through a random factor to obtain the random number generation private key stored in the random verifiable contract. The random verifiable contract can then call an off-chain random number generation service based on the random factor. Through the verifiable random function (VRF) in the random number generation service, the random number generation private key and the random factor are calculated to obtain the asset transfer random number.

[0089] It should be noted that the asset transfer contract and the random verifiable contract in this application embodiment can be pre-deployed in the blockchain by the management object. The management object can also initialize the public-private key pair (including the random number generation private key and the random number verification public key) corresponding to the random number generation algorithm (e.g., a verifiable random function, VRF). The random number generation private key can be stored in the random verifiable contract, and the random number verification public key can be made public. For example, when the random number generation algorithm is VRF, the calculation process of the asset transfer random number can include: Y = VRF_HASH(SK, X), proof = VRF_Proof(SK, X); where SK can represent the random number generation private key, X can represent the random factor, i.e., the input information of the random number generation algorithm VRF, Y can represent the asset transfer random number, and the output result of VRF, in addition to the asset transfer random number Y, can also include a zero-knowledge proof proof for verifying the asset transfer random number Y. The aforementioned asset transfer random number Y and zero-knowledge proof can be returned to the requesting device after the random distribution of virtual assets is completed, so that the requesting device can verify the correctness of the asset transfer random number Y and ensure the authenticity of the random distribution process of virtual assets based on the correctness of the asset transfer random number Y.

[0090] Step S103: Determine the target virtual asset corresponding to the asset transfer random number through the asset transfer contract, and return the target virtual asset and the asset transfer random number to the requesting device so that the requesting device can verify the validity of the target virtual asset based on the random factor, the asset transfer random number and the random number verification public key.

[0091] Specifically, after obtaining the asset transfer random number, the random verifiable contract can return the asset transfer random number to the asset transfer random number. The asset transfer random number can determine the target virtual asset that needs to be transferred to the target object. The asset transfer contract can transfer the target virtual asset to the target object's corresponding object account in the blockchain and return the target virtual asset and the asset transfer random number to the requesting device.

[0092] After receiving the target virtual asset and asset transfer random number returned by the blockchain node, the requesting device can verify the correctness of the asset transfer random number based on the random factor, the asset transfer random number, and the random number verification public key. If the asset transfer random number is verified to be correct (verification passes), it indicates that the process of the requesting device randomly obtaining the target virtual asset on the blockchain is genuine; if the asset transfer random number is verified to be incorrect (verification fails), it indicates that the process of the requesting device randomly obtaining the target virtual asset on the blockchain is untrusted and invalid.

[0093] For example, taking the aforementioned VRF as an example, in addition to returning the target virtual asset and the asset transfer random number X to the requesting device, the blockchain node can also return the zero-knowledge proof "proof" output along with the asset transfer random number X to the requesting device. The requesting device can calculate whether Y = VRF_P2H(proof) is true. If the above equation is not true, the verification is stopped, indicating that the asset transfer random number Y is verified incorrectly; if the above equation is true, the calculation of True / False = VRF_Verify(PK, X, proof) continues, where True indicates that the asset transfer random number Y has been verified successfully, False indicates that the verification has failed, and PK represents the public key for random number verification.

[0094] Please see Figure 5 , Figure 5 This is a schematic diagram illustrating the random distribution of virtual assets on a blockchain, provided in an embodiment of this application. For example... Figure 5 As shown, the target object can generate a random factor through request device 30a and encapsulate the asset domain request carrying the random factor into transaction tx2, which can then be uploaded to the blockchain network. Blockchain node 30b in the blockchain network can receive transaction tx2 and broadcast it in the blockchain network so that as many blockchain nodes as possible receive transaction tx2.

[0095] Each blockchain node in the blockchain network (e.g., blockchain node 30b) can execute transaction tx2. During the execution of transaction tx2, it can obtain the asset withdrawal request and the random factor carried by the asset withdrawal request. This random factor can be passed to the asset transfer contract in the blockchain. The asset transfer contract can run in the virtual machine of blockchain node 30b. This asset transfer contract can call a random verifiable contract deployed in the blockchain through the random factor. The random verifiable contract can call the off-chain random number generation service 30c based on the random factor. Through the random number generation algorithm (e.g., VRF) in the random number generation service 30c, an asset transfer random number generated by the random number generation private key and the random factor is obtained. The asset transfer contract can obtain the asset transfer random number generated by the random number generation service 30c, and based on the asset transfer business logic in the asset transfer contract, determine the target virtual asset corresponding to the asset transfer random number, and transfer the target virtual asset to the target account on the blockchain. Blockchain node 30b can return the target virtual asset and the asset transfer random number to requesting device 30a. Requesting device 30a can verify the correctness of the asset transfer random number based on the random factor, the asset transfer random number, and the public key verified by the random number. The verification process of the asset transfer random number by requesting device 30a can be found in the foregoing description and will not be repeated here.

[0096] It should be noted that in the blockchain network, transaction tx2 can be packaged into block 30d. For example, blockchain node 30b can package multiple transactions, including transaction tx2, into block 30d and broadcast block 30d in the blockchain network so that the other nodes in the blockchain network can verify the consensus of block 30d according to the consensus algorithm. When the consensus of block 30d is passed, block 30c can be officially added to the chain. That is, after the consensus of block 30c is passed, the block height of block 30c can be updated according to the maximum block height in the blockchain stored by blockchain node 30b. The updated block 30d is stored in the local database of blockchain node 30b. At this time, the updated block 30c is block N+i in the local database of blockchain node 30b. N+i is used to represent the block order of the updated block 30c in the local blockchain. N and i are both integers greater than or equal to 0.

[0097] In this embodiment, by deploying an asset transfer contract and a random verifiable contract in the blockchain, upon receiving an asset claim request from a requesting device, the asset transfer contract in the blockchain can be invoked based on the random factor carried in the asset claim request. This asset transfer contract can then invoke the random verifiable contract in the blockchain, and a private key (corresponding to the random verifiable contract) is generated based on the random factor and random number uploaded by the requesting device, thus generating a verifiable asset transfer random number. The asset transfer contract can determine the target virtual asset corresponding to the asset transfer random number. This target virtual asset and the asset transfer random number can be returned to the requesting device. The requesting device can verify the validity of the target virtual asset based on the random factor, the asset transfer random number, and the random number verification public key. In other words, by introducing a random verifiable contract and generating verifiable asset transfer random numbers under the blockchain, the randomness of virtual asset issuance can be guaranteed by verifying the correctness of the asset transfer random number, and the verifiability of virtual asset issuance can be improved.

[0098] Please see Figure 6 , Figure 6 This is a timing diagram illustrating a method for processing virtual assets in a blockchain, as provided in an embodiment of this application. Figure 6 As shown, the virtual asset processing method in this blockchain may include at least the following steps S201-S211:

[0099] Step S201: Receive the object registration request corresponding to the target object, obtain the object authentication information carried in the object registration request, verify the object authentication information through the object management interface, and obtain the identity authentication result corresponding to the object authentication information.

[0100] Specifically, if a target object wants to claim virtual assets on the blockchain, it needs to register. For example, if the requesting device can access the asset transfer backend service, the target object can send an object registration request to the requesting device. After receiving the object registration request corresponding to the target object, the requesting device can obtain the object authentication information carried in the object registration request. It can then verify the object authentication information through the object management interface to obtain the corresponding identity authentication result. The object management interface can call the management system used to manage object information, and the object authentication information can include the target object's ID photo, basic information, etc.

[0101] Step S202: When the identity authentication result indicates successful authentication, it is determined that the target object has the authority to initiate an asset retrieval request.

[0102] Specifically, when the authentication result indicates successful authentication, it means that the target object's identity has been recognized, and it can be determined that the target object has the authority to initiate an asset claim request. When the authentication result indicates failed authentication, it means that the target object's identity has not been recognized, and it can be determined that the target object does not yet have the authority to initiate an asset claim request. The target object needs to re-provide object authentication information for object registration.

[0103] Please see Figure 7 , Figure 7 This is a schematic diagram illustrating a scenario of object registration provided in an embodiment of this application. For example... Figure 7 As shown, when a target object wants to claim virtual assets on the blockchain, it needs to register the object with the asset transfer backend service. When the target object initiates an object registration request in the requesting device 40a, object authentication input boxes 40b and 40c can be displayed in the requesting device 40a. The target object can enter a front image of the document in object authentication input box 40b and a back image of the document in object authentication input box 40c. These front and back images of the document can be referred to as the target object's object authentication information.

[0104] After obtaining the front and back images of the ID card, the object management system 40d can be called through the object management interface. The front and back images are then verified based on the object information in the object management system 40d. If the front and back images uploaded by the target object match the existing target object information in the object management system 40d, authentication is successful, confirming that the target object has the authority to initiate an asset retrieval request. The successful authentication result is then returned to the requesting device 40a. If the front and back images uploaded by the target object do not match the existing target object information in the object management system 40d, authentication fails, confirming that the target object temporarily does not have the authority to initiate an asset retrieval request. The failed authentication result is then returned to the requesting device 40a, reminding the target object to re-register the object.

[0105] Step S203: Send an asset claim request carrying a random factor to the blockchain node.

[0106] Specifically, the requesting device can obtain the generation timestamp corresponding to the asset claim request, obtain a random factor based on the generation timestamp, add the random factor to the asset claim request, and send the asset claim request carrying the random factor to the blockchain nodes in the blockchain network.

[0107] Optionally, the requesting device can also obtain the public key of the target object, generate a random factor based on the public key, or use any random number generation method to generate the random factor. This application does not limit the method of generating the random factor.

[0108] Step S204: Verify the validity of the asset retrieval request and obtain the request verification result corresponding to the asset retrieval request.

[0109] Specifically, after receiving an asset claim request from a requesting device, a blockchain node can verify the validity of the request. This verification can include a signature verification process. For example, the blockchain node can obtain the digital signature carried in the asset claim request and the public key of the requesting device, i.e., the public key of the target object. Then, it can decrypt the digital signature based on the public key to obtain the first digest information corresponding to the digital signature. It can also perform a hash operation on the asset claim request based on a hash algorithm to obtain the second digest information corresponding to the asset claim request. If the first digest information and the second digest information are the same, the verification result of the asset claim request is determined to be a successful result, and the transaction containing the asset claim request can be stored in the transaction pool corresponding to the blockchain node.

[0110] In other words, to prevent the transaction containing the asset claim request from being maliciously tampered with during transmission, the target object can generate a key pair (including an object private key and an object public key; the object private key is managed by the target object itself or delegated to a specific service for management, and the public key can be communicated to all blockchain nodes in the blockchain network). The target object can use a hash algorithm to perform a hash operation on the asset claim request (which can also be understood as the transaction containing the asset claim request), generating a first digest information corresponding to the asset claim request, and encrypting the first digest information using the generated object private key. The encrypted first digest information is the digital signature corresponding to the asset claim request. The requesting device uploads the asset claim request carrying the digital signature to the blockchain network. After receiving the asset claim request carrying the digital signature, the blockchain node can obtain the object public key corresponding to the target object, decrypt the digital signature based on the object public key, and obtain the first digest information corresponding to the digital signature; then, according to the hash algorithm (i.e., the hash algorithm used by the target object when generating the digital signature), it performs a hash operation on the asset claim request received by the blockchain node to obtain the second digest information corresponding to the received asset claim request. If the first digest and the second digest are the same, it means the asset claim request has not been tampered with during the upload process, and the signature verification is successful. In other words, the verification result for the asset claim request indicates successful verification, and the transaction containing the asset claim request can be stored in the transaction pool. Transactions in the transaction pool can be used to package a new block. If the first digest and the second digest are different, it means the asset claim request may have been tampered with during the upload process, and the signature verification fails. In other words, the verification result for the asset claim request indicates verification failure.

[0111] It should be understood that before the target entity uploads the asset claim request via the requesting device, it has already notified the blockchain nodes in the blockchain network of its public key and the hash algorithm used to generate the digital signature. If the asset claim request is tampered with during the upload process, the digital signature received by the blockchain node is not the original digital signature generated by the target entity. Therefore, when the blockchain node tries to decrypt the digital signature using the public key corresponding to the transaction target entity, it will be unable to solve the problem. The hash algorithm can include, but is not limited to, SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.

[0112] Step S205: When the verification result indicates successful verification, obtain the random factor carried by the asset claim request, and call the asset transfer contract in the blockchain based on the random factor.

[0113] Specifically, when the verification result indicates successful verification, the random factor carried by the asset claim request can be obtained. When executing a transaction containing this asset claim request, the random factor can be used to invoke the asset transfer contract in the blockchain. If the random factor can serve as a condition for triggering the asset transfer contract, the asset transfer contract can be run in the virtual machine of the blockchain node.

[0114] Optionally, when the verification result indicates that the verification failed, it means that the asset retrieval request is invalid. The verification failure result can be returned to the requesting device to remind the target object to re-initiate the asset transfer request through the requesting device.

[0115] Step S206: Obtain the object information carried in the asset retrieval request. When the object information meets the asset retrieval conditions indicated by the asset transfer contract, determine that the target object associated with the requesting device has the authority to retrieve the asset.

[0116] Specifically, the asset transfer contract can specify the conditions for an object to claim virtual assets. For example, it can specify the number of times each object can randomly claim virtual assets on the blockchain, the time range for claiming virtual assets, and the time interval between claims. Blockchain nodes can obtain the object information carried in the asset claim request (e.g., object identifier, which can be used to uniquely identify the target object). When the object information meets the asset claim conditions indicated by the asset transfer contract, it can be determined that the target object has the right to claim assets. For example, if the asset transfer contract restricts each object to only randomly claim virtual resources on the blockchain once, and the target object has already claimed virtual resources on the blockchain, it can be determined that the target object does not have the right to claim assets; if the target object has never claimed virtual resources on the blockchain before, and this claim is its first, then it can be determined that the target object has the right to claim assets.

[0117] Step S207: Through the asset transfer contract, the random factor is passed into the random verifiable contract in the blockchain, and the random verifiable contract is executed based on the random factor.

[0118] Specifically, during the execution of an asset transfer contract, a blockchain node can invoke a random verifiable contract (e.g., a VRF contract) in the blockchain using a random factor. This means passing the random factor into the random verifiable contract and executing the random verifiable contract based on that random factor.

[0119] Step S208: Call the random number generation service through the random factor in the random verifiable contract, and perform calculations on the random number generation private key and random factor based on the verifiable random function in the random number generation service to obtain the asset transfer random number.

[0120] Specifically, blockchain nodes can obtain the private key for random number generation stored in a random verifiable contract. Through this contract, they can send a request to the random number generation service to retrieve random numbers. Upon receiving the request, the service can perform calculations on the private key and random factor based on a verifiable random function to obtain the asset transfer random number. This verifiable random function is just one example of a random number generation method, and this application does not limit the specific random number generation method. The process of generating the asset transfer random number can be found in step S102 above, and will not be repeated here.

[0121] Step S209: Determine the target virtual asset corresponding to the asset transfer random number through the asset transfer contract, and transfer the target virtual asset in the virtual asset set to the object account corresponding to the requesting device.

[0122] Specifically, after obtaining the asset transfer random number through a random number generation service, the random verifiable contract can return the asset transfer random number to the asset transfer contract. Within the asset transfer contract, the target virtual asset to be transferred can be determined based on the asset transfer random number. For example, a blockchain node can obtain a set of virtual assets and the quantity of each virtual asset contained in the set within the asset transfer contract. When executing the transfer business logic in the asset transfer contract, the target virtual asset for transfer is obtained based on the asset transfer random number and the asset quantity, and the target virtual asset in the set is transferred to the object account corresponding to the requesting device, i.e., the object account corresponding to the target object. The transfer process of the target virtual asset is completed on the blockchain.

[0123] In the transfer business logic of the asset transfer contract, rules can be specified for calculating the target virtual asset using an asset transfer random number. For example, the first virtual asset can be obtained by taking the remainder of the asset quantity from the asset transfer random number. If the first virtual asset does not belong to the virtual asset set, the remainder of the asset quantity from the first virtual asset can be taken to obtain the second virtual asset. If the second virtual asset belongs to the virtual asset set, the first virtual asset is determined as the target virtual asset for transfer. If the second virtual asset still does not belong to the virtual asset set, the above remainder operation can be performed until the obtained virtual asset belongs to the virtual asset set, and the virtual asset finally determined to belong to the virtual asset set is determined as the target virtual asset. It is understood that the aforementioned remainder operation is only an example in the embodiments of this application. This application can also use other operations to determine the final target virtual asset, such as rounding down the ratio between the asset transfer random number and the asset quantity, etc. This application does not limit this.

[0124] Step S210: Return the target virtual asset and asset transfer random number to the requesting device.

[0125] Specifically, after transferring the target virtual asset to the target object's corresponding object account, the target virtual asset and the asset transfer random number can be returned to the requesting terminal.

[0126] Step S211: Obtain the random verification result of the asset transfer random number by using the random factor, the asset transfer random number, and the random number verification public key. When the random verification result indicates that the verification is successful, the target virtual asset is determined to be valid.

[0127] Specifically, after receiving the target virtual asset and asset transfer random number returned by the blockchain node, the requesting device can verify the correctness of the asset transfer random number based on the random factor, the asset transfer random number, and the random number verification public key. When the random verification result indicates that the verification is successful, it means that the asset transfer random number has been verified as correct. Therefore, it can be considered that the process of the requesting device randomly receiving the target virtual asset on the blockchain is genuine, and the target virtual asset is valid.

[0128] When the random verification result indicates verification failure, it means that the asset transfer random number has been verified as incorrect. Therefore, it can be concluded that the process of the requesting device randomly acquiring the target virtual asset on the blockchain lacks authenticity, and the target virtual asset is invalid. The requesting terminal can send an asset transfer verification request to the blockchain node, so that the blockchain node can reallocate the target virtual asset for transfer to the requesting device. The verification process of the asset transfer random number by the requesting device can be found in the description of step S103 above, and will not be repeated here.

[0129] Please see Figure 8 , Figure 8 This is a flowchart illustrating a method for issuing virtual assets in a blockchain, as provided in an embodiment of this application. Figure 8 As shown, the virtual asset issuance method in the blockchain involves the interaction between the management object, the target object, the asset transfer service, the asset transfer contract, the random verifiable contract, and the random number generation service. The asset transfer service, also known as the asset transfer backend service, can be integrated into the requesting device. The asset transfer contract and the random verifiable contract can be deployed in the blockchain. The random verifiable contract can be a VRF contract, and the random number generation service can be called a VRF backend service. The implementation process of the virtual asset issuance method in the blockchain can include the following steps S301-S312:

[0130] Step S301: Initialize the public and private key pair for the random number generation algorithm.

[0131] Step S302: Deploy the asset transfer contract.

[0132] Step S303: Deploy a random verifiable contract carrying a private key for generating a random number.

[0133] Specifically, the managed object can generate a public-private key pair for a random number generation algorithm. For example, when the random number generation algorithm is VRF, a VRF public-private key pair can be initialized. This public-private key pair can include a random number generation private key and a random number verification public key. The random number generation private key can be stored in a random verifiable contract, and the random number verification public key can be made public. Subsequently, the managed object can deploy an asset transfer contract and a random verifiable contract carrying the random number generation private key in the blockchain. Steps S301-S302 are performed by the managed object before issuing virtual assets.

[0134] Step S304: Register and authenticate the target object.

[0135] Step S305: Real-name authentication of the target object is successful.

[0136] Specifically, the target object can undergo real-name identity authentication in the asset transfer service. The asset transfer service can verify the target object's object authentication information through the object management interface. Once authenticated, the target object is qualified to acquire virtual assets on the blockchain, such as having the authority to initiate an asset claim request.

[0137] Step S306: Request to claim virtual assets carrying a random factor.

[0138] Step S307: Invoke the asset transfer contract's claim interface based on the random factor.

[0139] Step S308: Verify the target object's asset retrieval permissions.

[0140] Specifically, the target object can send an asset claim request carrying a random factor to the blockchain node through the asset transfer service, and then call the claim interface of the asset transfer contract through the asset transfer service. It is assumed that the target object has delegated its private key to the asset transfer service for management. If the target object has not delegated its private key to the asset transfer service but manages it itself, it does not need to call the claim interface of the asset transfer contract through the asset transfer service; it can call it directly.

[0141] The asset transfer contract can be modified by passing in a random factor to verify whether the target object has the right to claim the asset. If the target object has the right to claim the asset, the subsequent steps can be executed. If the target object does not have the right to claim the asset, the execution of the asset transfer contract can be terminated.

[0142] Step S309: Input a random factor and obtain a random number.

[0143] Step S310: Send a request to obtain a random number.

[0144] Specifically, the asset transfer contract can pass a random factor to the random verifiable contract. The random verifiable contract can then send a request to the random number generation service to obtain a random number. The random number generation service can generate a private key based on the random factor and the random number, generate an asset transfer random number, and return the asset transfer random number to the asset transfer contract.

[0145] Step S311: Transfer the target virtual asset on the blockchain according to the asset transfer random number.

[0146] Specifically, after the asset transfer contract obtains the asset transfer random number returned by the random and verifiable contract, it can use this random number to perform operations such as modulo operations on the quantity of assets in the virtual asset set to determine the final target virtual asset to be transferred. Through the asset transfer contract, the aforementioned target virtual asset can be transferred to the target object's account on the blockchain, and the target virtual asset and the asset transfer random number will be returned to the target object.

[0147] Step S312: Verify the correctness of the random process using a random factor, an asset transfer random number, and a public key for verifying the random number.

[0148] Specifically, the target entity can verify the correctness of the asset transfer random number based on a random factor, the asset transfer random number, and the random number verification public key to ensure that the issuance of the target virtual assets is random. The verification process for the asset transfer random number can be found in the aforementioned description and will not be repeated here.

[0149] It is understood that the specific implementation of this application may involve the identity information, account information, etc. of the target object. When the above embodiments of this application are applied to specific products or technologies, the user's 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.

[0150] In this embodiment, by deploying an asset transfer contract and a random verifiable contract in the blockchain, upon receiving an asset claim request from a requesting device, the asset transfer contract in the blockchain can be invoked based on the random factor carried in the asset claim request. This asset transfer contract can then invoke the random verifiable contract in the blockchain, and a private key (corresponding to the random verifiable contract) is generated based on the random factor and random number uploaded by the requesting device, thus generating a verifiable asset transfer random number. The asset transfer contract can determine the target virtual asset corresponding to the asset transfer random number. This target virtual asset and the asset transfer random number can be returned to the requesting device. The requesting device can verify the validity of the target virtual asset based on the random factor, the asset transfer random number, and the random number verification public key. In other words, by introducing a random verifiable contract and generating verifiable asset transfer random numbers under the blockchain, the randomness of virtual asset issuance can be guaranteed by verifying the correctness of the asset transfer random number, and the verifiability of virtual asset issuance can be improved.

[0151] Please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a virtual asset processing device in a blockchain according to an embodiment of this application. It can be understood that this virtual asset processing device 1 can be applied to any blockchain node in the blockchain system; such as... Figure 9 As shown, the virtual asset processing device 1 in the blockchain may include: a contract calling module 11, a random number generation module 12, and a virtual asset determination module 13;

[0152] Contract invocation module 11 is used to receive asset retrieval requests sent by requesting devices and, based on the random factor carried in the asset retrieval request, invoke the asset transfer contract in the blockchain.

[0153] The random number generation module 12 is used to call the random verifiable contract in the blockchain through the asset transfer contract, generate a private key based on the random factor and the random number stored in the random verifiable contract, and generate random numbers for asset transfer.

[0154] The virtual asset determination module 13 is used to determine the target virtual asset corresponding to the asset transfer random number through the asset transfer contract, and return the target virtual asset and the asset transfer random number to the requesting device so that the requesting device can verify the validity of the target virtual asset based on the random factor, the asset transfer random number and the random number verification public key.

[0155] The specific implementation methods of the contract invocation module 11, random number generation module 12, and virtual asset determination module 13 can be found in [reference needed]. Figure 3 Steps S101-S103 in the corresponding embodiments will not be described again here.

[0156] In one or more embodiments, the contract invocation module 11 may include: a validity verification unit 111 and an asset transfer contract invocation unit 112;

[0157] The validity verification unit 111 is used to receive the asset retrieval request sent by the requesting device, verify the validity of the asset retrieval request, and obtain the request verification result corresponding to the asset retrieval request.

[0158] The asset transfer contract invocation unit 112 is used to obtain the random factor carried in the asset retrieval request when the request verification result indicates successful verification, and to invoke the asset transfer contract in the blockchain based on the random factor.

[0159] Optionally, the validity verification unit 111 includes: a signature acquisition subunit 1111, a hash operation subunit 1112, and a verification pass subunit 1113;

[0160] The signature acquisition subunit 1111 is used to acquire the digital signature carried in the asset retrieval request and the public key of the object corresponding to the requesting device;

[0161] The hash operation subunit 1112 is used to decrypt the digital signature based on the object public key to obtain the first digest information corresponding to the digital signature, and to perform a hash operation on the asset claim request based on the hash algorithm to obtain the second digest information corresponding to the asset claim request.

[0162] The verification passed subunit 1113 is used to determine the verification result of the asset retrieval request as a verification passed result if the first summary information is the same as the second summary information.

[0163] The specific functional implementation of the validity verification unit 111, the asset transfer contract invocation unit 112, and the signature acquisition subunit 1111, hash operation subunit 1112, and verification pass subunit 1113 included in the validity verification unit 111 can be found in [link to relevant documentation]. Figure 6 Steps S204 and S205 in the corresponding embodiments will not be described again here.

[0164] In one or more embodiments, the random number generation module 12 may include: an asset retrieval permission determination unit 121, a random verifiable contract invocation unit 122, a random number generation service invocation unit 123, and an asset transfer random number generation unit 124.

[0165] The asset retrieval authority determination unit 121 is used to obtain the object information carried in the asset retrieval request, and when the object information meets the asset retrieval conditions indicated by the asset transfer contract, it determines that the target object associated with the requesting device has asset retrieval authority.

[0166] The random verifiable contract invocation unit 122 is used to pass a random factor into a random verifiable contract in the blockchain through an asset transfer contract, and execute the random verifiable contract based on the random factor.

[0167] The random number generation service invocation unit 123 is used to obtain the random number generation private key stored in the random verifiable contract, and invoke the random number generation service through the random factor in the random verifiable contract; the random number generation service does not belong to the blockchain;

[0168] The asset transfer random number generation unit 124 is used to perform calculations on the random number generation private key and random factor based on the verifiable random function in the random number generation service to obtain the asset transfer random number.

[0169] The specific implementation methods of the asset retrieval permission determination unit 121, the random verifiable contract invocation unit 122, the random number generation service invocation unit 123, and the asset transfer random number generation unit 124 can be found in [link to documentation]. Figure 6 Steps S206-S208 in the corresponding embodiments will not be described again here.

[0170] In one or more embodiments, the virtual asset determination module 13 may include: an asset quantity acquisition unit 131 and a virtual asset transfer unit 132;

[0171] The asset quantity acquisition unit 131 is used to acquire a virtual asset set in the asset transfer contract and acquire the asset quantity of the virtual assets contained in the virtual asset set.

[0172] The virtual asset transfer unit 132 is used to execute the transfer business logic in the asset transfer contract, obtain the target virtual asset for transfer based on the asset transfer random number and the asset quantity, and transfer the target virtual asset in the virtual asset set to the object account corresponding to the requesting device.

[0173] Optionally, the virtual asset transfer unit 132 is specifically used for:

[0174] Execute the transfer business logic in the asset transfer contract, and perform a remainder operation on the asset quantity using the asset transfer random number to obtain the first virtual asset;

[0175] If the first virtual asset does not belong to the virtual asset set, then the second virtual asset is obtained by taking the remainder of the asset quantity using the first virtual asset.

[0176] If the second virtual asset belongs to the collection of virtual assets, then the first virtual asset is identified as the target virtual asset for transfer.

[0177] The specific functional implementation methods of the asset quantity acquisition unit 131 and the virtual asset transfer unit 132 can be found in [reference needed]. Figure 6 Step S209 in the corresponding embodiment will not be described again here.

[0178] In this embodiment, by deploying an asset transfer contract and a random verifiable contract in the blockchain, upon receiving an asset claim request from a requesting device, the asset transfer contract in the blockchain can be invoked based on the random factor carried in the asset claim request. This asset transfer contract can then invoke the random verifiable contract in the blockchain, and a private key (corresponding to the random verifiable contract) is generated based on the random factor and random number uploaded by the requesting device, thus generating a verifiable asset transfer random number. The asset transfer contract can determine the target virtual asset corresponding to the asset transfer random number. This target virtual asset and the asset transfer random number can be returned to the requesting device. The requesting device can verify the validity of the target virtual asset based on the random factor, the asset transfer random number, and the random number verification public key. In other words, by introducing a random verifiable contract and generating verifiable asset transfer random numbers under the blockchain, the randomness of virtual asset issuance can be guaranteed by verifying the correctness of the asset transfer random number, and the verifiability of virtual asset issuance can be improved.

[0179] Please see Figure 10 , Figure 10 This is a schematic diagram of another virtual asset processing device in a blockchain provided in this application embodiment. It can be understood that this virtual asset processing device 2 in the blockchain can be applied to a requesting device; such as... Figure 10 As shown, the virtual asset processing device 2 in the blockchain may include: a sending module 21 and a receiving module 22;

[0180] The sending module 21 is used to send an asset claim request carrying a random factor to the blockchain node, so that the blockchain node calls the asset transfer contract in the blockchain based on the random factor, and determines the target virtual asset corresponding to the asset transfer random number through the asset transfer contract; the asset transfer random number is generated based on the random factor and the random number generation private key stored in the random verifiable contract, and the random verifiable contract is called by the asset transfer contract;

[0181] The receiving module 22 is used to receive the target virtual asset and asset transfer random number returned by the blockchain node. By using the random factor, asset transfer random number and random number verification public key, a random verification result of the asset transfer random number is obtained. When the random verification result indicates that the verification is successful, the target virtual asset is determined to be valid.

[0182] The specific functional implementation of the sending module 21 and the receiving module 22 can be found in [reference needed]. Figure 6 Steps S203, S210-S211 in the corresponding embodiments will not be described again here.

[0183] In one or more embodiments, the virtual asset processing device 2 in the blockchain further includes: an audit request sending module 23, an authentication information verification module 24, a request permission determination module 25, and a random factor generation module 26;

[0184] The audit request sending module 23 is used to determine that the target virtual asset is not valid when the random verification result indicates that the verification has failed, and to send an asset transfer audit request to the blockchain node so that the blockchain node can reallocate the target virtual asset for transfer to the requesting device.

[0185] The authentication information verification module 24 is used to receive the object registration request corresponding to the target object, obtain the object authentication information carried in the object registration request, verify the object authentication information through the object management interface, and obtain the identity authentication result corresponding to the object authentication information.

[0186] The permission determination module 25 is used to determine that the target object has the permission to initiate an asset retrieval request when the identity authentication result indicates successful authentication.

[0187] The random factor generation module 26 is used to obtain the generation timestamp corresponding to the asset claim request, obtain the random factor based on the generation timestamp, and add the random factor to the asset claim request.

[0188] The specific implementation methods of the audit request sending module 23, authentication information verification module 24, request permission determination module 25, and random factor generation module 26 can be found in [reference needed]. Figure 6 Steps S201-S202 in the corresponding embodiments will not be described again here.

[0189] In this embodiment, by deploying an asset transfer contract and a random verifiable contract in the blockchain, the requesting device can generate a random factor locally and send an asset claim request carrying the random factor to the blockchain node. The blockchain node can call the asset transfer contract in the blockchain based on the random factor carried in the asset claim request, and then call the random verifiable contract in the blockchain through the asset transfer contract. The random verifiable contract can call a random number generation service to generate a verifiable asset transfer random number by generating a private key (the private key corresponding to the random verifiable contract) through the random factor and the random number. The asset transfer contract can determine the target virtual asset corresponding to the asset transfer random number. The target virtual asset and the asset transfer random number can be returned to the requesting device. The requesting device can verify the validity of the target virtual asset based on the random factor, the asset transfer random number, and the random number verification public key. That is, by introducing a random verifiable contract and generating verifiable asset transfer random numbers under the blockchain, the randomness of virtual asset issuance can be guaranteed by verifying the correctness of the asset transfer random number, and the verifiability of virtual asset issuance can be improved.

[0190] Please see Figure 11 , Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 11 As shown, the computer device 1000 can be a user terminal or a server; this is not a limitation. For ease of understanding, this application takes the computer device as a user terminal as an example. The computer device 1000 may include: a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to implement communication between these components. The user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a Wi-Fi interface). The memory 1004 may be a high-speed RAM memory or a non-volatile memory, such as at least one disk storage device. The memory 1005 may optionally be at least one storage device located remotely from the aforementioned processor 1001. Figure 11 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0191] The network interface 1004 in the computer device 1000 can also provide network communication functions, and the optional user interface 1003 can also include a display screen and a keyboard. Figure 11 In 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:

[0192] Receive the asset retrieval request sent by the requesting device, and invoke the asset transfer contract in the blockchain based on the random factor carried in the asset retrieval request;

[0193] By calling a random verifiable contract in the blockchain through an asset transfer contract, a private key is generated based on a random factor and the random number stored in the random verifiable contract, and a random number for asset transfer is generated.

[0194] The target virtual asset corresponding to the asset transfer random number is determined through the asset transfer contract. The target virtual asset and the asset transfer random number are returned to the requesting device so that the requesting device can verify the validity of the target virtual asset based on the random factor, the asset transfer random number and the random number verification public key.

[0195] Alternatively, processor 1001 can achieve the following:

[0196] A request to claim an asset carrying a random factor is sent to a blockchain node, so that the blockchain node calls the asset transfer contract in the blockchain based on the random factor. The asset transfer contract determines the target virtual asset corresponding to the random number of the asset transfer. The random number of the asset transfer is generated based on the random factor and the random number generation private key stored in the random verifiable contract. The random verifiable contract is called by the asset transfer contract.

[0197] The system receives the target virtual asset and asset transfer random number returned by the blockchain node. It obtains the random verification result of the asset transfer random number by using the random factor, the asset transfer random number, and the random number verification public key. When the random verification result indicates that the verification is successful, the target virtual asset is determined to be valid.

[0198] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 3 , Figure 6 as well as Figure 8 The description of the method for handling virtual assets in the blockchain in any corresponding embodiment can also be executed as described above. Figure 9 The description of the virtual asset processing device 1 in the blockchain in the corresponding embodiment, or the execution of the preceding text Figure 10 The description of the virtual asset processing device 2 in the blockchain in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0199] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the aforementioned virtual asset processing device 1 or virtual asset processing device 2 in the blockchain. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 3 , Figure 6 as well as Figure 8 The description of the virtual asset processing method in the blockchain in any corresponding embodiment is already provided and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments involved in this application, please refer to the description of the method embodiments of this application. As an example, program instructions can be deployed and executed on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network. These multiple computing devices distributed across multiple locations and interconnected via a communication network can constitute a blockchain system.

[0200] Furthermore, it should be noted that this application also provides a computer program product or computer program, which may include computer instructions, which may be stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor may execute the computer instructions, causing the computer device to perform the aforementioned actions. Figure 3 , Figure 6 as well as Figure 8 The description of the virtual asset processing method in the blockchain in any corresponding embodiment is already provided, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer program products or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0201] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0202] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

[0203] The modules in the device of this application embodiment can be merged, divided, and deleted according to actual needs.

[0204] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0205] 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 method for processing virtual assets in a blockchain, characterized in that, include: Receive the asset retrieval request sent by the requesting device, and invoke the asset transfer contract in the blockchain based on the random factor carried in the asset retrieval request; The asset transfer contract calls the random verifiable contract in the blockchain, and generates a private key based on the random factor and the random number stored in the random verifiable contract, thereby generating a random number for asset transfer. The asset transfer contract determines the target virtual asset corresponding to the asset transfer random number, and returns the target virtual asset and the asset transfer random number to the requesting device, so that the requesting device can verify the validity of the target virtual asset based on the random factor, the asset transfer random number and the random number verification public key.

2. The method according to claim 1, characterized in that, The receiving device sends an asset retrieval request, and based on the random factor carried in the asset retrieval request, invokes an asset transfer contract in the blockchain, including: Receive an asset retrieval request sent by the requesting device, verify the validity of the asset retrieval request, and obtain the request verification result corresponding to the asset retrieval request; When the verification result of the request indicates successful verification, the random factor carried by the asset claim request is obtained, and the asset transfer contract in the blockchain is invoked based on the random factor.

3. The method according to claim 2, characterized in that, The step of validating the asset claim request to obtain the request verification result corresponding to the asset claim request includes: Obtain the digital signature carried in the asset redemption request, and the public key of the object corresponding to the requesting device; The digital signature is decrypted based on the object's public key to obtain the first digest information corresponding to the digital signature. The asset redemption request is then hashed based on a hash algorithm to obtain the second digest information corresponding to the asset redemption request. If the first summary information is the same as the second summary information, then the verification result corresponding to the asset claim request is determined to be a verification pass result.

4. The method according to claim 1, characterized in that, The step of invoking a random verifiable contract in the blockchain through the asset transfer contract includes: Obtain the object information carried in the asset retrieval request; when the object information meets the asset retrieval conditions indicated by the asset transfer contract, determine that the target object associated with the requesting device has asset retrieval authority. The random factor is passed to the random verifiable contract in the blockchain through the asset transfer contract, and the random verifiable contract is executed based on the random factor.

5. The method according to claim 4, characterized in that, The step of generating a private key based on the random factor and the random numbers stored in the random verifiable contract, and generating a random number for asset transfer, includes: Obtain the random number generation private key stored in the random verifiable contract, and call the random number generation service through the random factor in the random verifiable contract; the random number generation service does not belong to the blockchain; The asset transfer random number is obtained by performing calculations on the random number generation private key and the random factor based on the verifiable random function in the random number generation service.

6. The method according to claim 1, characterized in that, The step of determining the target virtual asset corresponding to the asset transfer random number through the asset transfer contract includes: Obtain a virtual asset set from the asset transfer contract, and obtain the asset quantity of the virtual assets contained in the virtual asset set; Execute the transfer business logic in the asset transfer contract, obtain the target virtual asset for transfer based on the asset transfer random number and the asset quantity, and transfer the target virtual asset in the virtual asset set to the object account corresponding to the requesting device.

7. The method according to claim 6, characterized in that, The execution of the transfer business logic in the asset transfer contract, based on the asset transfer random number and the asset quantity, obtains the target virtual asset for transfer, including: Execute the transfer business logic in the asset transfer contract, and perform a remainder operation on the asset quantity using the asset transfer random number to obtain the first virtual asset; If the first virtual asset does not belong to the set of virtual assets, then the first virtual asset is used to perform a remainder operation on the asset quantity to obtain the second virtual asset. If the second virtual asset belongs to the set of virtual assets, then the first virtual asset is determined as the target virtual asset for transfer.

8. A method for processing virtual assets in a blockchain, characterized in that, include: An asset claim request carrying a random factor is sent to a blockchain node, so that the blockchain node calls an asset transfer contract in the blockchain based on the random factor, and determines the target virtual asset corresponding to the asset transfer random number through the asset transfer contract; the asset transfer random number is generated based on the random factor and the random number generation private key stored in the random verifiable contract, and the random verifiable contract is called by the asset transfer contract; The system receives the target virtual asset and the asset transfer random number returned by the blockchain node. Through the random factor, the asset transfer random number, and the random number verification public key, it obtains a random verification result of the asset transfer random number. When the random verification result indicates that the verification is successful, it determines that the target virtual asset is valid.

9. The method according to claim 8, characterized in that, Also includes: When the random verification result indicates that the verification failed, it is determined that the target virtual asset is not valid, and an asset transfer review request is sent to the blockchain node so that the blockchain node can reallocate the target virtual asset for transfer to the requesting device.

10. The method according to claim 8, characterized in that, Also includes: Receive an object registration request corresponding to the target object, obtain the object authentication information carried in the object registration request, verify the object authentication information through the object management interface, and obtain the identity authentication result corresponding to the object authentication information; When the identity authentication result indicates successful authentication, it is determined that the target object has the authority to initiate the asset retrieval request.

11. The method according to claim 8, characterized in that, Also includes: Obtain the generation timestamp corresponding to the asset claim request, obtain the random factor based on the generation timestamp, and add the random factor to the asset claim request.

12. A virtual asset processing device in a blockchain, characterized in that, include: The contract invocation module is used to receive asset retrieval requests sent by the requesting device, and invoke the asset transfer contract in the blockchain based on the random factor carried in the asset retrieval request. The random number generation module is used to call the random verifiable contract in the blockchain through the asset transfer contract, generate a private key based on the random factor and the random number stored in the random verifiable contract, and generate an asset transfer random number. The virtual asset determination module is used to determine the target virtual asset corresponding to the asset transfer random number through the asset transfer contract, and return the target virtual asset and the asset transfer random number to the requesting device so that the requesting device can verify the validity of the target virtual asset based on the random factor, the asset transfer random number and the random number verification public key.

13. A virtual asset processing device in a blockchain, characterized in that, include: The sending module is used to send an asset claim request carrying a random factor to a blockchain node, so that the blockchain node calls an asset transfer contract in the blockchain based on the random factor, and determines the target virtual asset corresponding to the asset transfer random number through the asset transfer contract; the asset transfer random number is generated based on the random factor and the random number generation private key stored in the random verifiable contract, and the random verifiable contract is called by the asset transfer contract; The receiving module is used to receive the target virtual asset and the asset transfer random number returned by the blockchain node, obtain the random verification result of the asset transfer random number through the random factor, the asset transfer random number and the random number verification public key, and determine that the target virtual asset is valid when the random verification result indicates that the verification is successful.

14. A computer device, characterized in that, Including memory and processor; The memory is connected to the processor, the memory is used to store computer programs, and the processor is used to invoke the computer programs so that the computer device performs the method according to any one of claims 1-11.

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

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

Images