CN112200567B

CN112200567B - Resource management method and device based on block chain and electronic equipment

Info

Publication number: CN112200567B
Application number: CN202011074740.1A
Authority: CN
Inventors: 陈敏聪; 朱剑雄; 李康; 蒋海滔
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-10-09
Filing date: 2020-10-09
Publication date: 2023-06-30
Anticipated expiration: 2040-10-09
Also published as: CN117010894A; CN112200567A

Abstract

One or more embodiments of the present disclosure provide a method, an apparatus, and an electronic device for managing resources based on a blockchain, which are applied to node devices in the blockchain; wherein, the service operator corresponding to the target service issues virtual resources on the blockchain; an intelligent contract for managing the virtual resources is deployed on the blockchain; the execution logic corresponding to the contract code of the intelligent contract comprises a confirmation logic and a plurality of business logics respectively corresponding to different asset management operations; the method comprises the following steps: receiving an intelligent contract call transaction corresponding to the intelligent contract, wherein the intelligent contract call transaction comprises an account identifier of a transaction sender; in response to the smart contract invoking the transaction, invoking validation logic in the smart contract, determining an asset management role of a transaction sender based on the account identification; and further calling business logic corresponding to the determined asset management role of the transaction sender in the intelligent contract to complete asset management operation corresponding to the business logic for the virtual resource.

Description

Resource management method and device based on block chain and electronic equipment

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a blockchain-based resource management method, a blockchain-based resource management device, and an electronic device.

Background

Blockchain technology, also known as distributed ledger technology, is an emerging technology that is commonly engaged in "accounting" by several computing devices, together maintaining a complete distributed database. The blockchain technology has the characteristics of decentralization, disclosure transparency, capability of participating in database recording by each computing device and capability of rapidly performing data synchronization among the computing devices, so that the blockchain technology is widely applied in a plurality of fields.

Disclosure of Invention

The specification provides a resource management method based on a block chain, which is applied to node equipment in the block chain; wherein, the service operator corresponding to the target service issues virtual resources on the blockchain; the block chain is provided with an intelligent contract for managing the virtual resources; the execution logic corresponding to the contract code of the intelligent contract comprises a confirmation logic and a plurality of business logics respectively corresponding to different asset management operations; the method comprises the following steps:

Receiving an intelligent contract call transaction corresponding to an intelligent contract; wherein the intelligent contract invoking transaction includes an account identification of a transaction sender;

invoking a transaction in response to the smart contract, invoking validation logic in the smart contract, determining an asset management role of the transaction sender based on the account identification; wherein, at least one asset management role is maintained in a contract account corresponding to the intelligent contract; different asset management roles respectively correspond to different business logics in the intelligent contract; the method comprises the steps of,

and further calling business logic corresponding to the determined asset management role of the transaction sender in the intelligent contract to finish asset management operation corresponding to the business logic for the virtual resource.

The specification also provides a resource management device based on the block chain, which is applied to node equipment in the block chain; wherein, the service operator corresponding to the target service issues virtual resources on the blockchain; the block chain is provided with an intelligent contract for managing the virtual resources; the execution logic corresponding to the contract code of the intelligent contract comprises a confirmation logic and a plurality of business logics respectively corresponding to different asset management operations; the device comprises:

The receiving module is used for receiving intelligent contract calling transaction corresponding to the intelligent contract; wherein the intelligent contract invoking transaction includes an account identification of a transaction sender;

a determining module, responsive to the smart contract invoking a transaction, invoking validation logic in the smart contract, determining an asset management role of the transaction sender based on the account identification; wherein, at least one asset management role is maintained in a contract account corresponding to the intelligent contract; different asset management roles respectively correspond to different business logics in the intelligent contract; the method comprises the steps of,

and the execution module is used for further calling business logic corresponding to the determined asset management role of the transaction sender in the intelligent contract and completing asset management operation corresponding to the business logic for the virtual resource.

The present specification also proposes an electronic device comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the steps of any of the methods described above by executing the executable instructions.

The present specification also proposes a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of any of the methods described above.

In the technical scheme, the asset roles are defined in the intelligent contracts deployed on the blockchain, and the calling authority of the business logic in the intelligent contracts is strictly controlled, so that the safety of virtual resource management can be improved.

Drawings

FIG. 1 is a schematic diagram of a smart contract creation process shown in the present specification;

FIG. 2 is a schematic diagram of the call flow of a smart contract shown in the present specification;

FIG. 3 is a schematic diagram of the creation and invocation flow of a smart contract shown in the present specification;

FIG. 4 is a schematic diagram of a blockchain-based resource management system shown in an exemplary embodiment of the present description;

FIG. 5 is a flowchart illustrating a method of blockchain-based resource management in accordance with an exemplary embodiment of the present description;

FIG. 6 is a flowchart illustrating a blockchain-based account creation method in accordance with an exemplary embodiment of the present description;

FIG. 7 is a flowchart illustrating a blockchain-based resource provisioning method in accordance with an exemplary embodiment of the present description;

FIG. 8 is a flowchart illustrating another blockchain-based resource provisioning method in accordance with an exemplary embodiment of the present description;

FIG. 9 is a flowchart illustrating another blockchain-based resource provisioning method in accordance with an exemplary embodiment of the present description;

FIG. 10 is a flowchart illustrating another blockchain-based resource provisioning method in accordance with an exemplary embodiment of the present description;

FIG. 11 is a flowchart illustrating another blockchain-based resource provisioning method in accordance with an exemplary embodiment of the present description;

fig. 12 is a hardware configuration diagram of an electronic device shown in an exemplary embodiment of the present specification;

FIG. 13 is a block diagram of a blockchain-based resource management device as shown in an exemplary embodiment of the present description.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with aspects of one or more embodiments of the present description as detailed in the accompanying claims.

It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chains (Public Blockchain), private chains (Private Blockchain) and federated chains (Consortium Blockchain). In addition, there may be combinations of the above types, such as private chain+federation chain, federation chain+public chain, and the like.

Among them, the highest degree of decentralization is the public chain. The public chain is represented by bitcoin, ethernet, and participants joining the public chain (also referred to as nodes in the blockchain) can read data records on the chain, participate in transactions, and compete for accounting rights for new blocks, etc. Moreover, each node can freely join or leave the network and perform relevant operations.

The private chain is the opposite, the write rights of the network are controlled by an organization or organization, and the data read rights are specified by the organization. In short, the private chain may be a weakly centralized system with strict restrictions on the nodes and a small number of nodes. This type of blockchain is more suitable for use within a particular organization.

The alliance chain is a block chain between public and private chains, and can realize 'partial decentralization'. Each node in the federation chain typically has an entity organization or organization corresponding thereto; nodes join the network by authorization and form a benefit-related federation, which collectively maintains blockchain operation.

Based on the basic characteristics of a blockchain, a blockchain is typically made up of several blocks. The time stamps corresponding to the creation time of the block are recorded in the blocks respectively, and all the blocks form a time-ordered data chain strictly according to the time stamps recorded in the blocks.

For real data generated in the physical world, the real data can be constructed into a standard transaction (transaction) format supported by a blockchain, then the transaction is issued to the blockchain, the node equipment in the blockchain performs consensus processing on the received transaction, and after the consensus is achieved, the node equipment serving as an accounting node in the blockchain packages the transaction into a block, and the persistence is performed in the blockchain.

Among other things, the consensus algorithm supported in the blockchain may include:

a first type of consensus algorithm, namely a consensus algorithm that node equipment needs to contend for the accounting rights of the accounting period of each round; for example, consensus algorithms such as Proof of Work (POW), proof of stock (POS), proof of commission (Delegated Proof of Stake, DPOS);

a second type of consensus algorithm, namely a consensus algorithm which pre-elects accounting nodes (without competing for accounting rights) for each round of accounting period; for example, a consensus algorithm such as the use of Bayesian fault tolerance (Practical Byzantine Fault Tolerance, PBFT) is used.

In blockchain networks employing a first type of consensus algorithm, node devices competing for accounting rights may perform a transaction after receiving the transaction. One of the node devices competing for the accounting rights may win out of the process of competing for the accounting rights in this round, becoming an accounting node. The accounting node may package the received transaction with other transactions to generate the latest chunk and send the generated latest chunk or chunks of the latest chunk to other node devices for consensus.

In blockchain networks employing a second type of consensus algorithm, node devices with accounting rights are already well-established prior to this round of accounting. Thus, after receiving a transaction, the node device may send the transaction to the billing node if it is not itself the billing node for the current round. For the billing node of the present round, the transaction may be performed during or before packaging the transaction with other transactions to generate the latest block. After generating the latest block, the accounting node may send the latest block or the block head of the latest block to other node devices for consensus.

As described above, regardless of which consensus algorithm is used by the blockchain as shown above, the accounting node of the round may package the received transaction to generate the latest chunk and send the generated latest chunk or chunks of the latest chunk to other node devices for consensus verification. If the other node equipment receives the latest block or the block head of the latest block, and is verified to have no problem, the latest block can be added to the end of the original blockchain, so that the accounting process of the blockchain is completed. Other nodes may also execute transactions contained in the block during the verification of the new block or block header from the accounting node.

In the blockchain domain, an important concept is account (account); taking an ethernet as an example, the ethernet generally divides accounts into two types, an external account and a contract account; the external account is an account directly controlled by the user, and is also called a user account; the contract account is an account (i.e., smart contract) that is created by the user through an external account and contains a contract code. Of course, for some blockchain projects (such as ant blockchains) derived from the ethernet-based architecture, the account types supported by the blockchains can be further expanded, which is not particularly limited in this specification.

For accounts in a blockchain, the account status of the account is typically maintained by a structure. When a transaction in a block is executed, the status of the account in the blockchain associated with the transaction will typically change.

Taking ethernet as an example, the structure of an account typically includes fields such as Balance, nonce, code, and Storage. Wherein:

a Balance field for maintaining a current account Balance of the account;

a Nonce field for maintaining a number of transactions for the account; the counter is used for guaranteeing that each transaction can be processed only once, and effectively avoiding replay attack;

A Code field for maintaining a contract Code for the account; in practical applications, only the hash value of the contract Code is usually maintained in the Code field; thus, the Code field is also commonly referred to as a Codehash field.

A Storage field for maintaining the stored contents of the account (default field value is null); for a contract account, a separate storage space is generally allocated to store the storage content of the contract account; this separate storage space is commonly referred to as the account store for the contract account. The storage content of the contract account is usually stored in the independent storage space in a data structure constructed as a MPT (Merkle Patricia Trie) tree; among them, the MPT tree constructed based on the stored contents of the contract account is also commonly referred to as Storage tree. Whereas the Storage field typically only maintains the root node of the Storage tree; thus, the Storage field is also commonly referred to as a Storage root field.

For the external account, the field values of the Code field and the Storage field shown above are null values.

For most blockchain projects, merkle trees are typically used; alternatively, data is stored and maintained based on the data structure of the Merkle tree. Taking the ethernet as an example, the ethernet uses an MPT tree (a Merkle tree variant) as a data organization form, which is used to organize and manage important data such as account status, transaction information, and the like.

The ethernet house designs three MPT trees, an MPT status tree, an MPT transaction tree, and an MPT receipt tree, respectively, for the data in the blockchain that needs to be stored and maintained. In addition to the above three MPT trees, there is actually one Storage tree built based on the stored contents of the contract account.

An MPT state tree, which is an MPT tree organized by account state data for all accounts in the blockchain; MPT transaction trees, which are MPT trees organized from transaction (transaction) data in a blockchain; the MPT receipt tree is an MPT tree organized by a transaction (receipt) receipt corresponding to each transaction generated after the transaction in the block is executed. The hash values of the root nodes of the MPT status tree, MPT transaction tree, and MPT receipt tree shown above are eventually added to the block header of the corresponding block.

Wherein, the MPT transaction tree and the MPT receipt tree correspond to blocks, i.e. each block has its own MPT transaction tree and MPT receipt tree. Whereas the MPT state tree is a global MPT tree and does not correspond to a particular block, but covers account state data for all accounts in the blockchain.

It should be noted that, each time the blockchain generates a latest block, after the transaction in the latest block is executed, the account status of the accounts (which may be external accounts or contract accounts) related to the executed transaction in the blockchain will also generally change accordingly;

For example, when a "transfer transaction" in a block is completed, the balances of the transfer account and the transfer account associated with the "transfer transaction" (i.e., the field values of the Balance fields of these accounts) will typically change.

After the transaction in the latest block generated by the block chain is executed, the node equipment needs to construct an MPT state tree according to the current account state data of all accounts in the block chain because the account state in the current block chain is changed, so as to maintain the latest state of all accounts in the block chain.

That is, each time a latest block is generated in the blockchain, and after the transaction in the latest block is executed, the account state in the blockchain is changed, and the node device needs to reconstruct an MPT state tree based on the latest account state data of all accounts in the blockchain. In other words, each block in the blockchain has an MPT state tree corresponding to it; the MPT status tree maintains the most current account status for all accounts in the blockchain after transactions in the blockchain have been executed.

In practical applications, whether public, private or federated, it is possible to provide smart contract (smart contract) functionality. Intelligent contracts on a blockchain are contracts on a blockchain that can be executed by a transaction trigger. The smart contracts may be defined in the form of codes.

Taking the ethernet as an example, a user is supported to create and invoke some complex logic in the ethernet network. The ethernet is used as a programmable blockchain, and the core of the ethernet is an Ethernet Virtual Machine (EVM), and each ethernet node can run the EVM. EVM is a graphics-based virtual machine through which various complex logic can be implemented. The user's issuing and invoking of the smart contract in the ethernet is running on the EVM. In fact, the EVM runs directly on virtual machine code (virtual machine bytecode, hereinafter "bytecode"), so the smart contract deployed on the blockchain may be bytecode.

As shown in fig. 1, bob sends a transaction (transaction) containing information to create a smart contract to the ethernet network, and each node may execute the transaction in the EVM. The From field of the transaction in fig. 1 is used To record an address of an account initiating creation of an intelligent contract, the contract code stored by the field value of the Data field of the transaction may be a byte code, and the field value of the To field of the transaction is an account null. After agreement is reached between nodes through the consensus mechanism, the intelligent contract is successfully created, and the subsequent user can call the intelligent contract.

After the intelligent contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific address; for example, "0x68e12cf284 …" in each node in FIG. 1 represents the address of this contract account created; the contract Code (Code) and the account store (Storage) will be saved in the account store of the contract account. The behavior of the smart contract is controlled by the contract code, and the account store of the smart contract maintains the state of the contract. In other words, the smart contract causes a virtual account to be generated on the blockchain that includes the contract code and account store.

The foregoing mentions that the Data field containing the transaction that created the smart contract holds may be the bytecode of the smart contract. Bytecode consists of a series of bytes, each of which can identify an operation. Based on various aspects of development efficiency, readability and the like, a developer can select a high-level language to write intelligent contract codes instead of directly writing byte codes. For example, a high-level language such as Solidity, serpent, LLL language may be employed. For smart contract code written in a high-level language, it may be compiled by a compiler to generate bytecodes that may be deployed onto a blockchain.

Taking the Solidity language as an example, the contract code written by the method is similar to the Class (Class) in the object-oriented programming language, and various members including state variables, functions, function modifiers, events and the like can be declared in one contract. The state variable is a value permanently stored in an account store (Storage) field of the smart contract for saving the state of the contract.

Still taking the ethernet as an example, as shown in fig. 2, bob sends a transaction containing the call intelligent contract information to the ethernet network, and each node can execute the transaction in the EVM. The From field of the transaction in fig. 2 is used for recording the address of the account initiating the call of the smart contract, the To field is used for recording the address of the called smart contract, and the Data field of the transaction is used for recording the method and parameters for calling the smart contract. After invoking the smart contract, the account status of the contract account may change. Subsequently, a client may view the account status of the contract account through the accessed blockchain node (e.g., node 1 in FIG. 2).

The intelligent contract can be independently executed at each node in the blockchain network in a specified mode, all execution records and data are stored on the blockchain, so that when the transaction is executed, transaction credentials which cannot be tampered and cannot be lost are stored on the blockchain.

A schematic diagram of creating a smart contract and invoking a smart contract is shown in fig. 3. To create an intelligent contract in the ethernet, the intelligent contract needs to be written, changed into byte codes, deployed to a blockchain and the like. The intelligent contract is called in the Ethernet, a transaction pointing to the intelligent contract address is initiated, EVM of each node can execute the transaction respectively, and intelligent contract codes are distributed and run in the virtual machine of each node in the Ethernet network.

The event mechanism of an intelligent contract is one way in which the intelligent contract interacts with an off-chain entity. For intelligent contracts deployed on blockchains, it is often not possible to interact directly with off-chain entities; for example, the intelligent contract typically cannot send the calling result of the intelligent contract to the calling initiator of the intelligent contract point-to-point after the completion of the call.

The calling results (including intermediate results and final calling results) generated during the calling process of the intelligent contract are generally recorded in the form of events (event) into a transaction log (transactions) of the transaction calling the intelligent contract, and are stored in the storage space of the node device. An off-chain entity needing to interact with the intelligent contract can acquire the calling result of the intelligent contract by monitoring the transaction log stored in the storage space of the node equipment;

For example, using ethernet as an example, the transaction log would ultimately be stored in the MPT receipt tree described above as part of the receipt (receipt) of the transaction pen invoking the smart contract. And the off-chain entity interacting with the intelligent contract can monitor the transaction receipts on the MPT receipt tree stored in the storage space of the node device and acquire events generated by the intelligent contract from the monitored transaction receipts.

Intelligent contracts deployed on blockchains can generally only reference data content stored on blockchains; in practical applications, however, for some complex business scenarios implemented based on smart contract technology, smart contracts may also need to reference external data on some off-chain data entities.

In this scenario, the intelligent contracts deployed on the blockchain may reference data on data entities outside the chain through the Oracle predictor, thereby enabling data interactions between the intelligent contracts and the real world data entities. Wherein the data entities outside the chain may include, for example, centralized servers or data centers deployed outside the chain, etc.

It should be noted that, the cross-chain relay is used to connect two blockchains, and the Oracle predictor is used to connect the blockchain and the data entity outside the chain, so as to realize the data interaction between the blockchain and the real world.

In practical application, when a prophetic contract on a blockchain is deployed, a prophetic contract corresponding to the prophetic contract can be deployed on the blockchain; the intelligent contracts of the propulsor are used for maintaining external data sent to the intelligent contracts on the blockchain by the propulsor; for example, external data that is predictive of smart contracts issued to blockchains may be stored in the account memory space of the predictive smart contracts.

When a target smart contract on the blockchain is called, external data required by the target smart contract can be read from the account storage space of the foresight smart contract to complete the calling process of the smart contract.

When external data is transmitted to the intelligent contract on the blockchain, the prophetic machine may adopt an active transmission mode or a passive transmission mode.

In one implementation, the data entity outside the chain may sign external data that needs to be provided to the target intelligent contract with the private key of the predictor and send the signed external data to the predictor intelligent contract; for example, in time, the signed external data may be sent to the predictor smart contract by a periodic transmission;

The intelligent contract of the propranator can maintain a CA certificate of the propranator, after receiving external data sent by a data entity outside the chain, the public key of the propranator maintained in the CA certificate can be used for verifying the signature of the external data, and after the signature passes the verification, the external data sent by the data entity outside the chain is stored in the account storage space of the intelligent contract of the propranator.

In another implementation, when a target smart contract on a blockchain is invoked, if external data required by the target smart contract is not read from the account storage space of the predictor smart contract, the predictor smart contract may interact with the predictor using an event mechanism of the smart contract, and the external data required by the target smart contract is sent to the account storage space of the predictor smart contract by the predictor.

For example, when a target smart contract on a blockchain is invoked, if external data required by the target smart contract is not read from the account storage space of the predictive smart contract, at this time, the predictive smart contract may generate an external data acquisition event, record the external data acquisition event into a transaction log of the transaction invoking the smart contract, and store the transaction log into the storage space of the node device; the predictor may monitor a transaction log generated by the predictor smart contract stored in the storage space of the node device, and after monitoring an external data acquisition event in the transaction log, respond to the monitored external data acquisition event, and send external data required by the target smart contract to the predictor smart contract.

Referring to fig. 4, fig. 4 is a schematic diagram of a blockchain-based resource management system according to an exemplary embodiment of the present disclosure.

In the blockchain-based resource management system as shown in fig. 4, a server that establishes a connection with a node device in the blockchain and a client that corresponds to a service operator (i.e., a client used by the service operator) and a plurality of clients that establish a connection with the server may be included in addition to the blockchain. Wherein the plurality of clients establishing a connection with the service may include a client corresponding to a service provider (i.e., a client used by the service provider), a client corresponding to a service broker (i.e., a client used by the service broker), and a client corresponding to a user for which the service is intended (i.e., a client used by the user); the servers may include servers corresponding to the operators of the blockchain (i.e., servers used by the operators of the blockchain).

The client may be deployed on an electronic device, which may be a server, a computer, a mobile phone, a tablet device, a notebook computer, a palm top (PDAs, personal Digital Assistants), etc.; the server side can also be deployed on an electronic device, and the electronic device can be a server, a computer and the like; the electronic equipment added into the blockchain as the node equipment can be a server, a computer, a mobile phone, a tablet equipment, a notebook computer, a palm computer and the like; this description is not limiting.

In practical applications, the services may include cultural entertainment services, such as: movie services, music services, online live services, online video play services, etc.

Taking a movie service as an example, a movie can be regarded as a service; for the service, the service operator may include an offeror of the movie, the service provider may include a movie theater line providing a projection service of the movie to the user, the service agent may include an agent for the sales of movie tickets corresponding to the movie theater and the movie, and the user may include a user purchasing movie tickets corresponding to the movie theater and the movie.

Taking a music service as an example, a song may be regarded as a service; for the service, the service operator may include a copyrighter of the song, the service provider may include an APP (Application) operator that provides a play service of the song to the user, the service agent may include an agent that proxies purchases of play rights corresponding to the APP and the song (e.g., purchases of membership of the APP, purchases of music albums containing the song, etc.), and the user may include a user who purchases play rights corresponding to the APP and the song.

Taking an online live service as an example, a live broadcast room can be regarded as a service; for the service, the service operator may include an operator of the live room, the service provider may include an operator of the APP that presents the live room to the user, the service broker may include a broker that brokers the charging of the charging balance corresponding to the live room, and the user may include a user that charges the charging balance corresponding to the live room.

Taking an online video playing service as an example, an online video set (for example, an online video set of a movie or a television show, an online video set of a variety program, etc.) can be regarded as a service; for the service, the service operator may include an operator of the online video set, the service provider may include an operator of an APP that presents the online video set to the user, the service broker may include a broker that brokers the placement of advertisements corresponding to the online video set, and the user may include a user viewing advertisements corresponding to the online video set.

To encourage users to consume a service (e.g., purchase movie tickets, purchase song play rights, play in a living room, watch advertisements in online videos, etc.) and autonomously promote the service to other users, the service operator may publish virtual resources corresponding to the service on the blockchain and issue virtual resources corresponding to the service to users who consume or promote the service through asset accounts created for the users on the blockchain.

In one embodiment, the virtual resource corresponding to the business may be value-anchored to a predetermined proportion of the total amount of future revenue for the business. The preset proportion can be preset by a service operator of the service.

Taking the movie service as an example, the virtual resource may be value anchored with at least some future box-office revenues of the movie service.

Taking a music service as an example, the virtual resource may be value anchored with at least part of the future copyright revenues of the music service.

Taking an online live service as an example, the virtual resource may be value anchored with at least a portion of the rewards of the online live service in the future.

Taking an online video playback service as an example, the virtual resource may be value anchored with at least some of the advertising revenue in the online video playback service's future.

Further, the virtual resource may include a virtual asset issued on the blockchain after freezing an asset issuance guarantee provided by a business operator of the business.

Specifically, the node device in the blockchain may perform freezing processing on an asset issuing guarantee provided by a service operator of the service, call asset issuing logic in an intelligent contract deployed on the blockchain after the freezing processing on the asset issuing guarantee is completed, create a preset number of virtual resources to form a virtual resource pool from the created virtual resources, issue the formed virtual resource pool to a contract account corresponding to the intelligent contract, and hold the virtual resource pool by the contract account corresponding to the intelligent contract; the virtual resources in the virtual resource pool are the virtual resources issued by the service operator on the blockchain for the service. The preset number may be specifically preset by a service operator of the service.

Taking a movie service as an example, assuming that the profit of a box office at a certain moment in the future of the movie service is 1000 ten thousand yuan; and, assuming that the preset proportion is 1%, the preset number is 10 ten thousand; the node device in the blockchain may first freeze the asset issuance guarantee provided by the sponsor of the movie service, and after the freezing of the asset issuance guarantee is completed, invoke the asset issuance logic in the smart contract deployed on the blockchain to create 10 parts per million virtual resources for the movie service, where each virtual resource has a value of 1000 ten thousand 1%/10 ten thousand = 1 yuan, so as to form a virtual resource pool from the 10 ten thousand virtual resources with a value of 1 yuan, and issue the formed virtual resource pool to a contract account corresponding to the smart contract, where the virtual resource pool is held by the contract account corresponding to the smart contract.

Subsequently, if the box office profit of the movie service rises to 2000 ten thousand yuan, the value of each virtual resource can be updated to 2000 ten thousand yuan 1%/10 ten thousand yuan = 2 yuan.

When the total amount of the asset release deposit provided by the service operator of the service is less than 20% of the total value of all the virtual assets released, the service operator may supplement the asset release deposit, so that the total amount of the asset release deposit is not less than 30% of the total value of all the virtual assets released.

Continuing with the above example of the movie service, assuming that the asset release guarantee provided by the sponsor of the movie service is 3 ten thousand yuan, when the value of each virtual resource is updated to 2 yuan, since 2 yuan/part is 10 ten thousand parts by 20% =4 ten thousand yuan, the asset release guarantee is greater than the asset release guarantee currently provided by the sponsor of the movie service, the sponsor of the movie service needs to supplement the asset release guarantee to 2 yuan/part by 10 ten thousand parts by 30% =6 ten thousand yuan.

In one embodiment shown, the server may be a Baas (Blockchain as a Service) platform that manages the blockchain.

In practice, multiple blockchains may be deployed and managed by the bias platform. In this case, when a corresponding asset account is created for a user, a corresponding asset account may be created for the user on the plurality of blockchains, respectively.

In one embodiment shown, the blockchain may be a coalition chain; the federation members of the federation chain may include operators of the federation chain corresponding to the servers and service operators of the services.

Referring to fig. 5, fig. 5 is a flowchart illustrating a blockchain-based resource management method according to an exemplary embodiment of the present disclosure.

In connection with the blockchain-based resource management system shown in fig. 4, the blockchain-based resource management method described above may be applied to node devices in the blockchain as shown in fig. 4; the blockchain-based resource management method may include the steps of:

step 501, receiving an intelligent contract call transaction corresponding to an intelligent contract; wherein the intelligent contract invoking transaction includes an account identification of a transaction sender;

step 502, calling a transaction in response to the intelligent contract, calling a confirmation logic in the intelligent contract, and determining an asset management role of the transaction sender based on the account identifier; wherein, at least one asset management role is maintained in a contract account corresponding to the intelligent contract; different asset management roles respectively correspond to different business logics in the intelligent contract;

and step 503, further calling business logic corresponding to the determined asset management role of the transaction sender in the intelligent contract, and completing asset management operation corresponding to the business logic for the virtual resource.

In this embodiment, an intelligent contract for managing the virtual resource may be deployed on the blockchain. Wherein the execution logic corresponding to the contract code of the smart contract includes validation logic and a plurality of business logic corresponding to different asset management operations, respectively.

For a service (referred to as a target service), the service operator of the target service, the service provider of the target service, the service proxy of the target service, and the client corresponding to the user of the target service, and the server may send an intelligent contract invoking transaction corresponding to the intelligent contract to the node device in the blockchain. Wherein the smart contract invocation transaction may include an account identification of a transaction sender that sent the smart contract invocation transaction.

In this embodiment, when receiving an intelligent contract invoking transaction corresponding to the intelligent contract, the node device in the blockchain may invoke a validation logic in the intelligent contract in response to the intelligent contract invoking transaction, and determine an asset management role of the transaction sender based on an account identifier in the intelligent contract invoking transaction.

It should be noted that, at least one asset management role is maintained in the contract account corresponding to the intelligent contract; different asset management roles correspond to different business logic in the smart contract, respectively.

In this embodiment, after determining the asset management role of the transaction sender, the node device in the blockchain may further invoke the business logic corresponding to the asset management role of the transaction sender in the intelligent contract, so as to complete the asset management operation corresponding to the business logic for the virtual asset issued by the business operator on the blockchain.

In one embodiment shown, the transaction sender may include an asset issuing user of the business operator; the intelligent contract invoking transaction may include an account identifier of the asset issuing user, and a freezing certificate of the asset issuing guarantee provided by the service operator; the asset management roles corresponding to the asset issuing user may include asset issuing roles; business logic corresponding to the asset issuing role may include credential verification logic and asset issuing logic.

In this case, the node device in the blockchain may invoke credential verification logic in the smart contract corresponding to the determined asset management role (i.e., asset issuing role) of the asset issuing user to perform validity verification on the frozen credential; if the validity check of the freezing certificate passes, further calling asset issuing logic corresponding to the asset issuing role, and creating a preset number of virtual resources to form a preset virtual resource pool.

In one embodiment shown, the transaction sender may include an asset management user of the business operator; the intelligent contract invoking transaction may include an account identification of the asset management user, and account identifications of a plurality of designated accounts holding virtual resources in the virtual resource pool; the asset management roles corresponding to the asset management user may include an asset allocation role; business logic corresponding to the asset allocation role may include asset allocation logic.

In this case, the node device in the blockchain may invoke the asset issuing logic in the smart contract corresponding to the determined asset management role (i.e., asset issuing role) of the asset management user, to issue the virtual resource in the preset virtual resource pool to a plurality of designated accounts holding the virtual resource for holding.

Further, in one embodiment shown, the plurality of designated accounts may include contract accounts corresponding to the smart contracts; the virtual resource held by the contract account is used for issuing the virtual resource to the user.

In actual practice, the specified accounts may also include asset accounts of partners (e.g., partners) participating in the targeted service. That is, the virtual resources in the preset virtual resource pool may be issued to the asset account of the partner, and held by the partner.

In one embodiment shown, the transaction sender may include a service agent; the intelligent contract invoking transaction may include an account identification of the service agent; the asset management roles corresponding to the business agents may include asset issuing roles; business logic corresponding to the asset issuance role may include asset issuance logic.

In this case, the node device in the blockchain may invoke the asset issuing logic in the smart contract corresponding to the determined asset management role (i.e., asset issuing role) of the service agent to issue the virtual resource to the asset account of the user of the target service.

The virtual resource issued to the user is a virtual resource held by the contract account corresponding to the smart contract.

In one embodiment shown, the transaction sender may include a service provider; the smart contract invocation transaction may include an account identification of the service provider; the asset management roles corresponding to the service provider may include an asset update role; business logic corresponding to the asset update role may include asset update logic.

In this case, the node device in the blockchain may invoke the asset update logic corresponding to the determined asset management role of the service provider in the smart contract to update the unit revenue profit amount corresponding to the virtual resource in the preset virtual resource pool.

In one embodiment shown, the transaction sender may include a user of the target service; the smart contract invocation transaction may include an account identification of the user; the asset management roles corresponding to the user may include an asset redemption role; business logic corresponding to the asset redemption character may include asset redemption logic.

In this case, the node device in the blockchain may invoke the asset exchange logic in the intelligent contract corresponding to the determined asset management role (i.e., asset exchange role) of the user, to exchange the virtual resource to be exchanged held by the asset account of the user.

In this embodiment, by defining the asset role in the intelligent contract deployed on the blockchain, the call authority of the business logic in the intelligent contract is strictly controlled, so that the security of virtual resource management can be improved.

Referring to fig. 6, fig. 6 is a flowchart illustrating a blockchain-based account creation method according to an exemplary embodiment of the present disclosure.

In connection with the blockchain-based resource management system shown in fig. 4, the blockchain-based account creation method described above may be applied to the server shown in fig. 4; the blockchain-based account creation method may include the steps of:

step 601, receiving an asset account creation request sent by a client; wherein the asset account creation request includes an account identification of a user account for which the user is logged into the client; the user account is a real-name account of the user;

step 602, responding to the asset account creation request, generating a unique virtual identity for the user, and binding the account identifier with the virtual identity;

Step 603, creating an asset account corresponding to the virtual identity on the blockchain; wherein the first asset account is for holding the virtual resource issued to the user.

In this embodiment, a user who needs to create an asset account may initiate an asset account creation request through a client corresponding to the user, and the client sends the asset account creation request to the server. Wherein the asset account creation request may include an account identification (e.g., account name) of a user account in which the user is logged into the client; the user account may specifically be a real-name account of the user.

For example, because the user's payment account is typically a real-name account that is registered based on the user's real-name information, the user may log into the client using his payment account and initiate an asset account creation request through the client.

In this embodiment, when the server receives the asset account creation request sent by the client, the server may respond to the asset account creation request to generate a unique virtual identity for the user, and bind an account identifier in the asset account creation request (i.e., an account identifier of a real-name account of the user) with the virtual identity.

For example, when generating the virtual identity for the user, hash calculation may be performed on the timestamp corresponding to the current time, the sub-base ID and the sub-table ID of the database storing the real name information of the user, the version number of the generation rule of the virtual identity, and the like, and the calculated hash value is used as the virtual identity of the user; or, the information can be spliced, and the character string obtained by splicing is used as the virtual identity of the user; or, the character strings obtained by splicing the information can be encoded according to the encoding rules preset by the technical staff, and the character strings obtained by encoding are used as the virtual identity of the user; this description is not limiting.

In this embodiment, after the server generates the virtual identifier for the user, an asset account corresponding to the virtual identifier may be created on the blockchain.

It should be noted that, the asset account corresponding to the virtual id may be a blockchain account for holding the virtual resource issued to the user; the blockchain account may specifically be a user account supported by the blockchain (i.e., an external account, referred to as a user asset account).

In one embodiment shown, before binding the account identifier in the asset account creation request with the virtual identity generated for the user, user real name information corresponding to the account identifier in the asset account creation request (i.e., real name information of the user) may be acquired, and other account identifiers associated with the user real name information may be queried. If other account identifications associated with the user real name information are queried, the queried other account identifications can be bound with the virtual identity generated for the user at the same time of binding the account identification in the asset account creation request with the virtual identity generated for the user.

In one embodiment, the user may also initiate an asset account binding request via the client, and the client may send the asset account binding request to the server. Wherein the asset account binding request may include identity information for the user (e.g., a cell phone number, license plate number, etc. of the user may be used to indicate the identity of the user).

When receiving the asset account binding request sent by the client, the server may respond to the asset account binding request, call account binding logic in an intelligent contract for managing the virtual resource, which is deployed on the blockchain, bind identity information in the asset account binding request with an asset account corresponding to a virtual identity generated for the user, and store the binding relationship in the blockchain.

In practical applications, the binding relationship may be maintained by the smart contract; i.e. the binding relationship can be stored in the storage space of the smart contract.

In one embodiment, the client may send the identity information of the user to an authentication end, so that the authentication end performs identity verification on the user based on the identity information.

Specifically, the authentication end may determine, based on the identity information, whether the user identity indicated by the identity information is the user itself. If the user identity indicated by the identity information is the user, the authentication end can determine that the identity verification corresponding to the user identity indicated by the identity information passes, so that a certificate with passed identity verification can be issued to the client, and the certificate indicates that the identity verification corresponding to the user identity indicated by the identity information passes.

In this case, the asset account binding request may include the credentials in addition to the identity information of the user; that is, the client may construct the asset account binding request based on the identity information of the user and the credentials, and send the asset account binding request to the server.

When receiving the asset account binding request sent by the client, the server can respond to the asset account binding request, call the intelligent contract deployed on the blockchain, perform validity check on the certificate in the asset account binding request, and bind the identity information in the asset account binding request with the asset account corresponding to the virtual identity generated for the user when the validity check on the certificate is passed.

In one embodiment shown, the authentication end may be a third party certification authority. When the certificate is issued to the client by the third party certification authority serving as the certification end, the third party certification authority can carry out digital signature based on the private key of the third party certification authority.

In this case, when the server receives the asset account binding request sent by the client, the server may invoke the smart contract deployed on the blockchain in response to the asset account binding request, and verify the digital signature of the credential in the asset account binding request based on a public key corresponding to the private key of the third party certification authority maintained by the smart contract; if the verification is passed, the validity verification of the certificate in the asset account binding request can be determined to be passed, so that the identity information in the asset account binding request can be bound with the asset account corresponding to the virtual identity generated for the user.

In the illustrated embodiment, in order to implement binding the identity information in the asset account binding request with the asset account corresponding to the virtual id generated for the user, and store the binding relationship in the blockchain, the server may first determine whether an asset account corresponding to the identity information in the asset account binding request has been created on the blockchain.

If the asset account corresponding to the identity information in the asset account binding request is already created on the blockchain, the server can directly bind the asset account corresponding to the identity information in the asset account binding request with the asset account corresponding to the virtual identity generated for the user, and store the binding relationship in the blockchain.

If the asset account corresponding to the identity information in the asset account binding request is not created on the blockchain, the server may create the asset account corresponding to the identity information in the asset account binding request on the blockchain, bind the created asset account corresponding to the identity information in the asset account binding request with the asset account corresponding to the virtual identity generated for the user, and store the binding relationship in the blockchain.

The asset account corresponding to the identity information in the asset account binding request may be a blockchain account for holding a virtual resource issued to the user; the blockchain account may specifically be a temporary account (referred to as a temporary asset account) created by the above-described smart contract deployed on the blockchain.

In this embodiment, a real-name account for holding virtual resources can be created for a user on the blockchain, and identity information of the user is not used when the real-name account is created, so that the risk of privacy disclosure of the user can be reduced.

Referring to fig. 7, fig. 7 is a flowchart illustrating a blockchain-based resource provisioning method according to an exemplary embodiment of the present disclosure.

In connection with the blockchain-based resource management system as shown in fig. 4, the blockchain-based resource provisioning method described above may be applied to node devices in the blockchain as shown in fig. 4; the blockchain-based resource issuing method may include the steps of:

step 701, receiving a first transaction for issuing virtual resources to a user; wherein the first transaction includes identity information of the user;

step 702, in response to the first transaction, when it is determined that a temporary asset account corresponding to the identity information is created on the blockchain, invoking resource issuing logic in the intelligent contract, and issuing virtual resources allocated from a preset virtual resource pool to the user to the temporary asset account for holding;

Step 703, when it is determined that the identity information is bound to the user asset account, invoking resource transfer logic in the intelligent contract, and transferring virtual resources held by the temporary asset account corresponding to the identity information to the user asset account for holding.

In this embodiment, an intelligent contract for managing the virtual resources described above may be deployed on the blockchain.

Further, referring to the embodiment shown in fig. 6, for a user, on one hand, a unique virtual identity may be generated for the user, and an asset account (referred to as a user asset account) corresponding to the virtual identity of the user may be created on the blockchain; alternatively, an asset account (referred to as a temporary asset account) corresponding to the identity information of the user may be created on the blockchain. Wherein the user asset account may be a user account (i.e., an external account) supported by the blockchain; the temporary asset account may be a temporary account created by the above-described smart contract deployed on the blockchain.

The service operator, the service provider, or the service agent may initiate a request for issuing virtual resources to the user through a corresponding client, so that a transaction (referred to as a first transaction) for issuing virtual resources to the user is constructed by the client or a server that establishes a connection with the client based on the request, and the first transaction is transmitted to a node device in the blockchain. Wherein the first transaction may include identity information of the user.

In this embodiment, when the node device in the blockchain receives the first transaction sent by the client, it may first determine, in response to the first transaction, whether a temporary asset account corresponding to the identity information in the first transaction has been created on the blockchain; if so, then the resource issuing logic in the intelligent contract deployed on the blockchain can be further invoked, virtual resources are allocated to the user from a virtual resource pool for maintaining the virtual resources issued on the blockchain by the service operator, the virtual resources allocated to the user are issued from the virtual resource pool to temporary asset accounts corresponding to the identity information in the first transaction, and the temporary asset accounts corresponding to the identity information in the first transaction hold the virtual resources allocated to the user.

For example, assume that a business operator of a movie initiates a transaction for issuing a number of 10 virtual resources to a user based on the mobile phone number of the user through a corresponding client. In this case, the client may send the transaction to a node device in the blockchain to first determine, by the node device in the blockchain upon receipt of the transaction sent by the client, in response to the transaction, whether a temporary asset account corresponding to the user's cell phone number has been created on the blockchain; if so, then the resource issuing logic in the intelligent contract deployed on the blockchain can be further invoked, the 10 virtual resources allocated to the user are issued from the virtual asset pool to the temporary asset account corresponding to the mobile phone number of the user, and the 10 virtual resources allocated to the user are held by the temporary asset account corresponding to the mobile phone number of the user.

In this embodiment, the node device in the blockchain may further respond to the first transaction, and first determine whether the identity information in the first transaction is already bound to the user asset account corresponding to the virtual identity of the user (i.e., determine whether the binding relationship between the identity information in the first transaction and the user asset account corresponding to the virtual identity of the user is stored in the blockchain); if so, then the resource transfer logic in the intelligent contract deployed on the blockchain can be further invoked, virtual resources held by the temporary asset account corresponding to the identity information in the first transaction are transferred to the user asset account corresponding to the virtual identity of the user, and the user asset account corresponding to the virtual identity of the user continues to hold the virtual resources allocated to the user.

Continuing with the above example, assuming that it is determined that the user's phone number has been bound to the user's user asset account corresponding to the user's virtual identity, resource transfer logic in the smart contract deployed on the blockchain may be further invoked to transfer the 10 virtual resources held by the temporary asset account corresponding to the user's phone number to the user's user asset account corresponding to the user's virtual identity, and the 10 virtual resources allocated to the user may be continued to be held by the user's user asset account corresponding to the user's virtual identity.

In one illustrated embodiment, to determine whether a temporary asset account has been created on the blockchain that corresponds to identity information in the first transaction, first determination logic in the smart contract deployed on the blockchain may be invoked to determine whether a temporary asset account has been created on the blockchain that corresponds to identity information in the first transaction.

If a temporary asset account corresponding to the identity information in the first transaction has been created on the blockchain, resource provisioning logic in the intelligent contract may be further invoked to allocate virtual resources for the user from a virtual resource pool for maintaining virtual resources published on the blockchain by the business operator, and to provision the virtual resources allocated for the user from the virtual resource pool to the temporary asset account corresponding to the identity information in the first transaction, the virtual resources allocated for the user being held by the temporary asset account corresponding to the identity information in the first transaction.

If the temporary asset account corresponding to the identity information in the first transaction is not created on the blockchain, the account creation logic in the intelligent contract may be further invoked to create the temporary asset account corresponding to the identity information in the first transaction on the blockchain, and after the temporary asset account is created, the resource issuing logic in the intelligent contract is further invoked to allocate virtual resources for the user from a virtual resource pool for maintaining virtual resources issued by the business operator on the blockchain, and issue virtual resources allocated for the user from the virtual resource pool to the created temporary asset account, where the created temporary asset account holds virtual resources allocated for the user.

In one illustrated embodiment, to determine whether the identity information in the first transaction has been bound to the user asset account corresponding to the user's virtual identity, second determination logic in the smart contract deployed on the blockchain may be invoked to query binding relationships stored in the blockchain to determine whether the identity information in the first transaction has been bound to the user asset account corresponding to the user's virtual identity.

If the identity information in the first transaction is already bound to the user asset account corresponding to the virtual identity of the user, resource transfer logic in the intelligent contract may be further invoked to transfer the virtual resource held by the temporary asset account corresponding to the identity information in the first transaction to the user asset account corresponding to the virtual identity of the user, and the user asset account corresponding to the virtual identity of the user continues to hold the virtual resource allocated to the user.

If the identity information in the first transaction is not already bound with the user asset account corresponding to the virtual identity of the user, it can be considered that virtual resource transfer is not required for the user asset account at present.

In one embodiment shown, the user may also initiate a request for binding identity information through the client, so that a transaction (referred to as a second transaction) for binding identity information is constructed by the client or a server connected to the client based on the request, and the second transaction is sent to the node device in the blockchain. Wherein the second transaction may include identity information of the user.

Upon receiving the second transaction, the node device in the blockchain may invoke third determination logic in an intelligent contract deployed on the blockchain in response to the second transaction to determine whether a temporary asset account has been created on the blockchain that corresponds to the identity information in the second transaction.

If a temporary asset account corresponding to the identity information in the second transaction is already created on the blockchain, account binding logic in the intelligent contract can be further invoked to bind the identity information in the second transaction with the user asset account corresponding to the virtual identity of the user, and the binding relationship is stored in the blockchain.

If a temporary asset account corresponding to the identity information in the second transaction has not been created on the blockchain, it may be deemed that there is currently no binding of identity information for the user asset account corresponding to the virtual identity of the user.

When the identity information in the second transaction is bound to the user asset account corresponding to the virtual identity of the user, the binding relationship between the identity information in the second transaction and the user asset account corresponding to the virtual identity of the user may be directly stored in the blockchain, or the binding relationship between the temporary asset account corresponding to the identity information in the second transaction and the user asset account corresponding to the virtual identity of the user may be stored in the blockchain.

In this case, the second transaction may include the credential in addition to the identity information of the user; that is, the client or a server establishing a connection with the client may construct the second transaction based on the identity information of the user and the credential and send the second transaction to the node device in the blockchain.

When the node device in the blockchain receives the second transaction, the node device in the blockchain can respond to the second transaction, call the verification logic in the intelligent contract deployed on the blockchain, perform validity verification on the certificate in the second transaction, and bind the identity information in the second transaction with the asset account corresponding to the virtual identity of the user when the validity verification on the certificate is passed.

In this case, upon receipt of the second transaction, the node device in the blockchain may invoke verification logic in a smart contract deployed on the blockchain to verify a digital signature of the credential in the second transaction based on a public key corresponding to a private key of the third party certificate authority maintained by the smart contract in response to the second transaction; if the verification is passed, the verification of the validity of the certificate in the second transaction can be determined to be passed, so that the identity information in the second transaction can be bound with the asset account corresponding to the virtual identity of the user.

In the technical scheme, the temporary asset account corresponding to the user identity information is created on the blockchain, so that the service operator can issue the virtual asset to the user based on the user identity information, and when the user authorizes to transfer the personal identity to the user asset account corresponding to the VID of the user created on the blockchain, the virtual resource held by the temporary asset account can be further transferred to the user asset account to finish resource issue, thereby avoiding the problem of failure in virtual resource issue caused by incapability of knowing the account identification of the user's asset account by the service operator.

Referring to fig. 8, fig. 8 is a flowchart illustrating another blockchain-based resource provisioning method according to an exemplary embodiment of the present disclosure.

In connection with the blockchain-based resource management system shown in fig. 4, the above blockchain-based resource issuing method may be applied to the server shown in fig. 4; the blockchain-based resource issuing method may include the steps of:

step 801, receiving a consumption record corresponding to the target service and a user identifier of a popularization user corresponding to the consumption record;

step 802, performing data verification on the consumption record;

And step 803, in response to the data verification of the consumption record passing, invoking resource issuing logic in the intelligent contract, and issuing virtual resources distributed for the popularization user from a preset virtual resource pool to an asset account of the popularization user for holding.

For a service (referred to as a target service), a service provider of the target service, a service proxy of the target service, or a client corresponding to a user of the target service may send a consumption record corresponding to the target service and a user identifier of a promotion user corresponding to the consumption record (e.g., an account identifier of a user account in which the promotion user logs in to the client, a mobile phone number of the promotion user, a license plate number of the promotion user, etc.) to the server.

In one embodiment shown, the consumption record corresponding to the target service may be sent to the server by the corresponding client by one or more of the service provider, the service agent, or the combination of the three.

Taking a promotion of a movie showing for a movie theater as an example, a promoting user may share a ticketing link corresponding to the movie theater and the movie to the promoted user. The ticket purchasing link may include a user identification of the promotional user. The promoted user can enter a ticket purchasing interface through the ticket purchasing link to purchase movie tickets corresponding to the movie theatre and the movie through the ticket purchasing interface. After ticket purchase is completed, the client corresponding to the promoted user can generate a consumption record, and the user identification of the promoted user obtained from the ticket purchase link and the consumption record are sent to the server.

In practical application, the ticket purchasing link may be a URL (Uniform Resource Locator ) address; the user identification of the promoting user may carry a portion of the URL address for carrying parameters.

In this embodiment, when the service end receives the consumption record corresponding to the target service and the user identifier of the promotion user corresponding to the consumption record, data verification may be performed on the consumption record, and when the data verification on the consumption record passes, resource issuing logic in the intelligent contract deployed on the blockchain is further invoked, so as to allocate virtual resources for the promotion user from a virtual resource pool for maintaining virtual resources issued by the service operator on the blockchain, and issue the virtual resources allocated for the promotion user from the virtual resource pool to an asset account of the promotion user, where the asset account of the promotion user holds the virtual resources allocated for the promotion user.

In practical applications, the data verification may be performed on the consumption record by using a common data verification method, for example: the digital signature may be performed on the consumption record, and subsequently the digital signature of the consumption record may be validated.

In one embodiment, the user identifier of the promotion user may include identity information of the promotion user.

In this case, referring to the embodiment shown in FIG. 7, the server may first determine whether an asset account corresponding to the promotional user's identity information has been created on the blockchain before invoking the resource issuance logic in the smart contract deployed on the blockchain.

Wherein the asset account corresponding to the identity information of the promoting user may be a blockchain account for holding virtual resources issued to the promoting user.

Specifically, the server may invoke first determination logic in the above-described smart contract deployed on the blockchain to determine whether an asset account corresponding to the identity information of the promoting user has been created on the blockchain.

If an asset account corresponding to the identity information of the promoting user is already created on the blockchain, resource issuing logic in the intelligent contract can be further invoked to allocate virtual resources for the promoting user from a virtual resource pool for maintaining the virtual resources issued on the blockchain by the service operator, and issue the virtual resources allocated for the promoting user from the virtual resource pool to an asset account corresponding to the identity information of the promoting user, and hold the virtual resources allocated for the promoting user by the asset account corresponding to the identity information of the promoting user.

If the asset account corresponding to the identity information of the promotion user is not created on the blockchain, the account creation logic in the intelligent contract can be further called, the asset account corresponding to the identity information of the promotion user is created on the blockchain, after the asset account creation is completed, the resource issuing logic in the intelligent contract is further called, virtual resources are allocated to the promotion user from a virtual resource pool for maintaining the virtual resources issued on the blockchain by the service operator, the virtual resources allocated to the promotion user are issued from the virtual resource pool to the asset account corresponding to the identity information of the promotion user, and the virtual resources allocated to the promotion user are held by the asset account corresponding to the identity information of the promotion user.

In one implementation shown, referring to the example shown in fig. 6, on the one hand, a unique virtual identity may be generated for the promoting user and an asset account (i.e., a user asset account) corresponding to the promoting user's virtual identity may be created on the blockchain; on the other hand, the asset account (i.e., temporary asset account) corresponding to the identity information of the promotional user may specifically be a temporary account created by the smart contract deployed on the blockchain.

In this case, referring to the embodiment shown in fig. 7, the server may further determine whether the user asset account corresponding to the virtual identity of the promotion user is already bound with the identity information of the promotion user.

Specifically, the server may invoke a second determination logic in the intelligent contract deployed on the blockchain to query the binding relationship stored in the blockchain to determine whether the identity information of the promoting user is already bound to the user asset account corresponding to the virtual identity of the promoting user.

If the identity information of the promoting user is already bound with the user asset account corresponding to the virtual identity of the promoting user, the resource transfer logic in the intelligent contract can be further invoked, after the virtual resource distribution for the temporary asset account corresponding to the identity information of the promoting user is completed, the virtual resource held by the temporary asset account corresponding to the identity information of the promoting user is transferred to the user asset account corresponding to the virtual identity of the promoting user, and the virtual resource allocated to the user is continuously held by the user asset account corresponding to the virtual identity of the promoting user.

If the identity information of the popularization user is not bound with the user asset account corresponding to the virtual identity of the popularization user, the user asset account can be considered to be not required to be transferred with virtual resources.

In one embodiment, the user identifier of the promotion user may include a virtual identity identifier of the promotion user.

In this case, the server may invoke the resource transfer logic in the intelligent contract deployed on the blockchain, allocate a virtual resource for the promoting user from a virtual resource pool for maintaining virtual resources issued on the blockchain by the service operator, and directly issue the virtual resource allocated for the promoting user from the virtual resource pool to a user asset account corresponding to the virtual identity of the promoting user, where the user asset account corresponding to the virtual identity of the promoting user holds the virtual resource allocated for the promoting user.

In the illustrated embodiment, if a refund process corresponding to the consumption record is performed with respect to the consumption record, the service provider, the service agent, or the client corresponding to the user may transmit the refund record corresponding to the consumption record to the server.

When receiving a refund record corresponding to the consumption record, the server side can perform data verification on the refund record, and when the data verification on the refund record passes, further call resource transfer logic in the intelligent contract deployed on the blockchain, and transfer the virtual resource allocated to the popularization user for the consumption record held by the asset account of the popularization user to the virtual resource pool.

In one illustrated embodiment, the contract accounts corresponding to the smart contracts deployed on the blockchain may maintain a state machine corresponding to each virtual resource allocated for the promoting user. The state machine comprises a pre-allocation state and an allocation success state; the initial state of the state machine is a pre-allocation state.

In this case, for a certain virtual resource allocated to the promotion user, it may be determined whether the above-mentioned target task corresponding to the virtual resource has been completed; if the target task has been completed, state maintenance logic in the intelligent contract may be further invoked to switch the state corresponding to the virtual resource held by the promoted user's asset account from a pre-allocation state to an allocation success state.

It should be noted that, the user cannot exchange the virtual resource in the pre-allocation state as the virtual resource to be exchanged; that is, the user can only redeem the virtual resource for the virtual resource in the allocation success state.

In an embodiment shown, after the data verification of the consumption record passes, the server may further store the consumption record in a local service database, and obtain a state corresponding to a virtual resource allocated to the promotion user for the consumption record and maintained by a contract account corresponding to the intelligent contract deployed on the blockchain, so as to set a corresponding state for the consumption record stored in the local service database based on the obtained state corresponding to the virtual resource.

In the above technical solution, on one hand, a consuming user corresponding to a consuming record of a target service may obtain a virtual resource issued by a service operator; on the other hand, the popularization user corresponding to the consumption record of the target service can also obtain the virtual resource issued by the service operator; therefore, in the operation process of the target service, the user can be stimulated to consume the target service, and the user can be stimulated to actively conduct service popularization for the target service, so that the popularization cost of the target service can be remarkably reduced. In addition, when virtual resources are issued to the consumption user and the popularization user at the same time, the number of the virtual resources issued to the popularization user is larger than that of the consumption user, so that the user can be further stimulated to carry out service popularization, and the popularization cost of the target service is reduced.

Referring to fig. 9, fig. 9 is a flowchart illustrating another blockchain-based resource provisioning method according to an exemplary embodiment of the present disclosure.

step 901, receiving a first intelligent contract call transaction corresponding to the intelligent contract; the first intelligent contract invoking transaction comprises a consumption record corresponding to the target service and a user identification of a popularization user corresponding to the consumption record;

step 902, responding to the first intelligent contract call transaction, calling first check logic in the intelligent contract, and checking data for the consumption record;

and step 903, in response to the data verification of the consumption record passing, further calling a resource issuing logic in the intelligent contract, and issuing the virtual resources distributed for the popularization user from a preset virtual resource pool to an asset account of the popularization user for holding.

In this embodiment, the node device in the blockchain may receive a smart contract invocation transaction (referred to as a first smart contract invocation transaction) corresponding to the smart contract. The first intelligent contract invoking transaction may include a consumption record corresponding to the target service, and a user identifier of a promotion user corresponding to the consumption record. Subsequently, the node device in the blockchain may invoke a transaction in response to the first intelligent contract, invoke a check logic (referred to as a first check logic) in the intelligent contract, perform data check on the consumption record, and further invoke a resource issuing logic in the intelligent contract deployed on the blockchain when the data check on the consumption record passes, allocate a virtual resource for the promotion user from a virtual resource pool for maintaining a virtual resource issued on the blockchain by the service operator, and issue the virtual resource allocated for the promotion user from the virtual resource pool to an asset account of the promotion user, where the asset account of the promotion user holds the virtual resource allocated for the promotion user.

In this embodiment, the consumption record corresponding to the target service includes one or more of the following combinations: a consumption record sent by a service agent corresponding to the target service; a consumption record sent by a service provider corresponding to the target service; and the consumption record is sent by the user client corresponding to the target service.

In this embodiment, the virtual resource performs value anchoring with a predetermined proportion of the total amount of revenue in the future of the target business.

In this embodiment, the virtual resource includes: freezing the asset release guarantee provided by the service operator, and then releasing virtual assets in the blockchain;

in this embodiment, the preset virtual resource pool may include a virtual resource pool held by a contract account corresponding to the intelligent contract.

In this case, the node device in the blockchain may further call the asset issuing logic in the intelligent contract in response to a prompt event that the freezing process of the asset issuing guarantee provided by the service operator is completed, create a preset number of virtual resources to form the preset virtual resource pool, and issue the virtual resource pool to a contract account corresponding to the intelligent contract for holding.

In this embodiment, the node device in the blockchain may further receive a second smart contract invocation transaction corresponding to the smart contract; wherein the second smart contract invoking transaction includes a refund record corresponding to the consumption record. Subsequently, the node device in the blockchain may respond to the second intelligent contract to invoke a transaction, invoke second check logic in the intelligent contract, perform data check on the refund record, and invoke resource transfer logic in the intelligent contract to transfer the virtual resource held by the asset account of the promoting user to the preset virtual resource pool when the data check on the refund record passes.

In this embodiment, the contract account corresponding to the intelligent contract may maintain a state machine corresponding to the virtual resource allocated to the promotion user; the state machine comprises a pre-allocation state and an allocation success state; the initial state of the state machine is a pre-allocation state.

In this case, the node device in the blockchain may further invoke state maintenance logic in the intelligent contract in response to a prompt event for the completion of the target service, to switch the virtual resource held by the asset account of the promoting user from a pre-allocation state to an allocation success state.

In this embodiment, the node device in the blockchain may further store the consumption record in the blockchain in response to the data verification for the consumption record passing; and acquiring a state corresponding to the virtual resource which is maintained by the intelligent contract and allocated to the popularization user, and setting a corresponding state for the consumption record stored in the blockchain based on the acquired state corresponding to the virtual resource.

It should be noted that, for a specific manner of executing the steps 901 to 903 by the node device in the blockchain, reference may be made to a specific manner of executing the steps 801 to 803 by the bias platform in the blockchain-based resource allocation method shown in fig. 8, which is not described herein in detail.

Referring to fig. 10, fig. 10 is a flowchart illustrating another blockchain-based resource provisioning method according to an exemplary embodiment of the present disclosure.

Step 1001, receiving a consumption record corresponding to the target service, and user identifiers of a consumption user and a popularization user corresponding to the consumption record;

step 1002, performing data verification on the consumption record;

and step 1003, in response to the data verification of the consumption record passing, invoking resource issuing logic in the intelligent contract to issue virtual resources allocated to the consumption user and/or the popularization user from a preset virtual resource pool to asset accounts of the consumption user and/or the popularization user for holding.

For a service (referred to as a target service), a service provider of the target service, a service proxy of the target service, or a client corresponding to a user of the target service may send a consumption record corresponding to the target service, and user identifications of a consuming user and a promoting user corresponding to the consumption record (e.g., account identifications of user accounts of users logged in the client, mobile phone numbers of users, license plates of users, etc.) to the server.

Taking a promotion of a movie showing for a movie theater as an example, a promoting user may share a ticketing link corresponding to the movie theater and the movie to the promoted user. The ticket purchasing link may include a user identification of the promotional user. The promoted user may enter a ticket purchasing interface through the ticket purchasing link as a consuming user to purchase movie tickets corresponding to the movie theatre and the movie through the ticket purchasing interface. After ticket purchase is completed, the client corresponding to the consumer can generate a consumption record, and send the user identification of the consumer, the user identification of the popularization user obtained from the ticket purchase link, and the consumption record to the server.

In this embodiment, when receiving the consumption record corresponding to the target service and the user identifiers of the consumption user and the promotion user corresponding to the consumption record, the server may perform data verification on the consumption record, and further invoke the resource issuing logic in the intelligent contract deployed on the blockchain when the data verification on the consumption record passes, to allocate virtual resources for the consumption user and/or the promotion user from the virtual resource pool for maintaining the virtual resources issued by the service operator on the blockchain, and issue the allocated virtual resources to the asset account of the consumption user and/or the promotion user for holding.

Specifically, in one aspect, virtual resources can be allocated to the consuming user from the virtual resource pool, and the virtual resources allocated to the consuming user are issued from the virtual resource pool to an asset account of the consuming user, and the asset account of the consuming user holds the virtual resources allocated to the consuming user; on the other hand, virtual resources can be allocated to the consumer user from the virtual resource pool, the virtual resources allocated to the popularization user are issued to the asset account of the popularization user from the virtual resource pool, and the asset account of the popularization user holds the virtual resources allocated to the popularization user.

In practical application, virtual resources can be allocated only for the consumer users or the popularization users; alternatively, virtual resources may be allocated to the consumer and the promotion user at the same time.

When virtual resources are simultaneously allocated to the consumer and the promotion user, the number of virtual resources allocated to the promotion user is larger than the number of virtual resources allocated to the consumer.

In one embodiment shown, the consumption record further includes a timestamp corresponding to the time of consumption. In this case, the number of virtual resources allocated to the consuming user and/or the promoting user is inversely proportional to the value of the timestamp in the consumption record. That is, the smaller the value of the timestamp in the consumption record (i.e., the earlier the corresponding consumption time), the greater the number of virtual resources allocated to the consuming user and/or the promoting user; the larger the value of the timestamp in the consumption record (i.e., the later the corresponding consumption time), the fewer the number of virtual resources allocated to the consuming user and the promoting user.

It should be noted that the step of allocating virtual resources to the consuming user is substantially the same as the step of allocating virtual resources to the promoting user, and the difference between the two steps is only that the number of virtual resources allocated to the consuming user may be different from the number of virtual resources allocated to the promoting user.

The step of allocating the virtual resource to the promotion user will be specifically described below by taking the allocation of the virtual resource to the promotion user as an example.

If an asset account corresponding to the identity information of the promoting user is already created on the blockchain, resource issuing logic in the intelligent contract can be further invoked to allocate virtual resources for the promoting user from a virtual resource pool for maintaining the virtual resources issued on the blockchain by the service operator, and issue the virtual resources allocated for the promoting user from the virtual resource pool to an asset account corresponding to the identity information of the promoting user, and hold the virtual resources allocated for the user by the asset account corresponding to the identity information of the promoting user.

If the asset account corresponding to the identity information of the promotion user is not created on the blockchain, the account creation logic in the intelligent contract can be further called, the asset account corresponding to the identity information of the promotion user is created on the blockchain, after the asset account creation is completed, the resource issuing logic in the intelligent contract is further called, virtual resources are allocated to the promotion user from a virtual resource pool for maintaining the virtual resources issued on the blockchain by the service operator, the virtual resources allocated to the promotion user are issued from the virtual resource pool to the asset account corresponding to the identity information of the promotion user, and the virtual resources allocated to the user are held by the asset account corresponding to the identity information of the promotion user.

In this case, the server may invoke the resource transfer logic in the intelligent contract deployed on the blockchain, allocate a virtual resource for the promoting user from a virtual resource pool for maintaining virtual resources issued on the blockchain by the service operator, and directly issue the virtual resource allocated for the promoting user from the virtual resource pool to a user asset account corresponding to the virtual identity of the promoting user, where the user asset account corresponding to the virtual identity of the promoting user holds the virtual resource allocated for the user.

When receiving a refund record corresponding to the consumption record, the server side can perform data verification on the refund record, further call resource transfer logic in the intelligent contract deployed on the blockchain when the data verification on the refund record passes, transfer virtual resources, which are held by the asset account of the consumption user and are allocated to the consumption user for the consumption record, to the virtual resource pool again, and transfer virtual resources, which are held by the asset account of the popularization user and are allocated to the popularization user for the consumption record, to the virtual resource pool.

In one embodiment shown, the contract accounts corresponding to the smart contracts deployed on the blockchain may maintain state machines corresponding to each virtual resource allocated for the consuming user and the promoting user. The state machine comprises a pre-allocation state and an allocation success state; the initial state of the state machine is a pre-allocation state.

In this case, for a certain virtual resource allocated to the consuming user or the promoting user, it may be determined whether the above-described target task corresponding to the virtual resource has been completed; if the target task has been completed, state maintenance logic in the intelligent contract may be further invoked to switch the state corresponding to the virtual resource held by the asset account of the consuming user or the asset account of the promoting user from a pre-allocation state to an allocation success state.

In an embodiment shown, after the data verification of the consumption record passes, the server may further store the consumption record in a local service database, and acquire a state corresponding to a virtual resource allocated to the consumption user and the promotion user for the consumption record maintained by a contract account corresponding to the intelligent contract deployed on the blockchain, so as to set a corresponding state for the consumption record stored in the local service database based on the acquired state corresponding to the virtual resource.

In one embodiment, the service provider of the target service may send the revenue data corresponding to the target service to the service end through a client corresponding to the service provider.

When the server receives the revenue data sent by the client, the server may perform data verification on the revenue data, and further invoke calculation logic in the intelligent contract deployed in the blockchain when the data verification on the revenue data passes, update the total revenue profit amount of the target service based on the revenue data, update the total revenue profit amount of the target service based on the updated total revenue profit amount, and maintain the total issue amount of virtual resources in a virtual resource pool of virtual resources issued by the service operator on the blockchain, further calculate a unit revenue profit amount corresponding to the virtual resources in the virtual resource pool (for example, unit revenue amount=total revenue profit amount/total issue amount of virtual resources), and maintain the calculated unit revenue profit amount in a contract account corresponding to the intelligent contract.

In one embodiment, the user of the target service may initiate a resource exchange request corresponding to the target service through a client corresponding to the user, and the client sends the resource exchange request to the server. Wherein the resource redemption request may include the number of virtual resources to be redeemed (i.e., the number of virtual resources held by the user's asset account).

When the server receives the resource exchange request sent by the client, the server may respond to the resource exchange request, call resource exchange logic in the intelligent contract deployed on the blockchain, and calculate an exchange amount corresponding to the number of virtual resources to be exchanged based on the unit revenue profit amount corresponding to the virtual resources maintained by the contract account corresponding to the intelligent contract (for example, the exchange amount=the unit revenue profit amount).

Subsequently, based on the calculated exchange amount, transfer processing may be performed from the deposit account corresponding to the service operator of the target service to the fund account corresponding to the user.

In one embodiment, the redemption request may further include an account identifier of an asset account holding the virtual resource to be redeemed (i.e., an account identifier of the user's asset account).

In this case, after the transfer process is completed, the server may further call the asset verifying logic in the smart contract deployed on the blockchain, and perform verifying processes on the virtual resource to be converted held in the corresponding asset account for the account identifier, for example: and removing the virtual resource to be converted from the asset account corresponding to the account identifier.

Referring to fig. 11, fig. 11 is a flowchart illustrating another blockchain-based resource provisioning method according to an exemplary embodiment of the present disclosure.

step 1101, receiving a first smart contract call transaction corresponding to the smart contract; the first intelligent contract invoking transaction comprises a consumption record corresponding to the target service, and user identifiers of a consumption user and a popularization user corresponding to the consumption record;

step 1102, responding to the first intelligent contract call transaction, calling first check logic in the intelligent contract, and checking data for the consumption record;

and step 1103, in response to the data verification of the consumption record passing, further invoking resource issuing logic in the intelligent contract to issue virtual resources allocated to the consumption user and/or the popularization user from a preset virtual resource pool to asset accounts of the consumption user and/or the popularization user for holding.

In this embodiment, the node device in the blockchain may receive a smart contract invocation transaction (referred to as a first smart contract invocation transaction) corresponding to the smart contract. The first intelligent contract invoking transaction may include a consumption record corresponding to the target service, and user identifications of a consumption user and a popularization user corresponding to the consumption record. Subsequently, the node device in the blockchain may invoke a transaction in response to the first intelligent contract, invoke a check logic (referred to as a first check logic) in the intelligent contract, perform data check on the consumption record, and further invoke a resource issuing logic in the intelligent contract deployed on the blockchain when the data check on the consumption record passes, allocate a virtual resource for the consumption user and/or the promotion user from a virtual resource pool for maintaining the virtual resource issued on the blockchain by the service operator, and issue the allocated virtual resource to an asset account of the consumption user and/or the promotion user for holding.

In this embodiment, the number of virtual resources allocated to the promotion user is greater than the number of virtual resources allocated to the promotion user.

In this embodiment, the consumption record further includes a timestamp corresponding to the consumption time; the number of virtual resources allocated to the consuming user and/or the promoting user is inversely proportional to the value size of the timestamp.

In this embodiment, the receiving a consumption record corresponding to the target service includes any one or more of the following combinations: receiving a consumption record sent by a service agent corresponding to the target service; receiving a consumption record sent by a service provider corresponding to the target service; and receiving the consumption record sent by the user client corresponding to the target service.

In this embodiment, the virtual resource includes: and freezing the asset release guarantee provided by the business operator, and then releasing the virtual asset in the blockchain.

In this embodiment, the node device in the blockchain may further receive a second smart contract invocation transaction corresponding to the smart contract; wherein the second smart contract invoking transaction includes a refund record corresponding to the consumption record. Subsequently, the node device in the blockchain may invoke a transaction in response to the second smart contract, invoke second check logic in the smart contract, perform data verification on the refund record, and invoke resource transfer logic in the smart contract to transfer the virtual resources held by the asset account of the consuming user and/or the promoting user to the preset virtual resource pool when the data verification on the refund record passes.

In this embodiment, the contract account corresponding to the intelligent contract may maintain a state machine corresponding to the virtual resource allocated to the consuming user and/or the promoting user; the state machine comprises a pre-allocation state and an allocation success state; the initial state of the state machine is a pre-allocation state.

In this case, the node device in the blockchain may further invoke state maintenance logic in the intelligent contract in response to a prompt event for the completion of the target service, to switch the virtual resource held by the asset account of the consuming user and/or the promoting user from a pre-allocation state to an allocation success state.

In this embodiment, the node device in the blockchain may further store the consumption record in a local service database in response to the data verification for the consumption record passing; and acquiring a state corresponding to the virtual resource which is maintained by the intelligent contract and is allocated to the consumption user and/or the popularization user, and setting a corresponding state for the consumption record stored in a local service database based on the acquired state corresponding to the virtual resource.

In this embodiment, the node device in the blockchain may further receive a third smart contract invocation transaction corresponding to the smart contract; and the third intelligent contract invoking transaction comprises the revenue data sent by the service provider corresponding to the target service. Subsequently, the node device in the blockchain can respond to the third intelligent contract to call a transaction, call third check logic in the intelligent contract, conduct data check on the revenue data, call calculation logic in the intelligent contract when the data check on the revenue data is passed, update the revenue total amount of the target service based on the revenue data, and further calculate the unit revenue profit amount corresponding to the virtual resources in the virtual resource pool based on the revenue profit amount of the preset proportion in the revenue total amount and the release total amount of the virtual resources in the virtual resource pool, and maintain the unit revenue profit amount in the contract account corresponding to the intelligent contract.

In this embodiment, the node device in the blockchain may further receive a resource exchange transaction sent by a user client corresponding to the target service; wherein the resource redemption transaction includes the number of virtual resources to be redeemed. Subsequently, the node device in the blockchain can respond to the resource exchange transaction, call resource exchange logic in the intelligent contract, calculate the exchange amount corresponding to the number of virtual resources to be exchanged based on the unit revenue amount maintained by the contract account corresponding to the intelligent contract, generate an exchange event corresponding to the exchange amount, and issue the exchange event to the blockchain for certification, so that when the payment platform monitors the exchange event existing in the blockchain, based on the exchange amount, transfer processing is performed from a guarantee fund account corresponding to the service operator to a fund account corresponding to the user client.

In this embodiment, the resource redemption request may further include an account identification of an asset account holding the virtual resource to be redeemed.

In this case, after the transfer processing is completed, the node device in the blockchain may further call the asset verification logic in the intelligent contract, and perform verification processing on the virtual resource to be converted, which is held in the asset account corresponding to the account identifier.

It should be noted that, for a specific manner of executing the steps 1101 to 1103 by the node device in the blockchain, reference may be made to a specific manner of executing the steps 1001 to 1003 by the bias platform in the blockchain-based resource allocation method shown in fig. 10, which is not described herein in detail.

Corresponding to the embodiments of the blockchain-based resource management method described above, the present specification also provides embodiments of a blockchain-based resource management device.

Embodiments of the blockchain-based resource management apparatus of the present specification may be applied to electronic devices. The apparatus embodiments may be implemented by software, or may be implemented by hardware or a combination of hardware and software. Taking software implementation as an example, the device in a logic sense is formed by reading corresponding computer program instructions in a nonvolatile memory into a memory by a processor of an electronic device where the device is located for operation. In terms of hardware, as shown in fig. 12, a hardware structure diagram of an electronic device where a blockchain-based resource management device is located in the present specification is shown, and in addition to the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 12, the electronic device where the device is located in the embodiment generally includes other hardware according to the actual function of the blockchain-based resource management, which will not be described herein.

Referring to fig. 13, fig. 13 is a block diagram of a blockchain-based resource management device according to an exemplary embodiment of the present disclosure. The blockchain-based resource management device 130 may be applied to an electronic device as shown in fig. 12, which may be a node device in a blockchain; wherein, the service operator corresponding to the target service issues virtual resources on the blockchain; the block chain is provided with an intelligent contract for managing the virtual resources; the execution logic corresponding to the contract code of the intelligent contract comprises a confirmation logic and a plurality of business logics respectively corresponding to different asset management operations; the apparatus 130 may include:

A receiving module 1301 for receiving an intelligent contract call transaction corresponding to an intelligent contract; wherein the intelligent contract invoking transaction includes an account identification of a transaction sender;

a determining module 1302, responsive to the smart contract invoking a transaction, invoking validation logic in the smart contract, determining an asset management role of the transaction sender based on the account identification; wherein, at least one asset management role is maintained in a contract account corresponding to the intelligent contract; different asset management roles respectively correspond to different business logics in the intelligent contract; the method comprises the steps of,

and the execution module 1303 further calls business logic corresponding to the determined asset management role of the transaction sender in the intelligent contract to complete asset management operation corresponding to the business logic for the virtual resource.

In this embodiment, the transaction sender includes an asset issuing user of a business operator; the intelligent contract invoking transaction comprises an account identifier of the asset issuing user and a freezing certificate of the asset issuing guarantee provided by the service operator; the asset management roles corresponding to the asset issuing users include asset issuing roles; business logic corresponding to the asset issuing roles includes credential verification logic and asset issuing logic;

The execution module 1303:

invoking a credential verification logic in the intelligent contract corresponding to the determined asset management role of the asset issuing user, and performing validity verification on the freezing credential; and if the validity check is passed, further calling asset issuing logic corresponding to the asset management role, and creating a preset number of virtual resources to form a preset virtual resource pool.

In this embodiment, the transaction sender includes an asset management user of a business operator; the intelligent contract invoking transaction comprises account identifications of the asset management user and account identifications of a plurality of designated accounts holding virtual resources in the virtual resource pool; the asset management roles corresponding to the asset management users include an asset allocation role; business logic corresponding to the asset allocation role includes asset allocation logic;

the execution module 1303:

and invoking asset issuing logic corresponding to the determined asset management roles of the asset management users in the intelligent contracts, and issuing virtual resources in the preset virtual resource pools to the specified accounts for holding.

In this embodiment, the plurality of designated accounts includes a contract account corresponding to the smart contract; the virtual resources held by the contract account are used for issuing to the user.

In this embodiment, the transaction sender includes a service agent; the intelligent contract invoking transaction comprises an account identifier of the service agent; the asset management roles corresponding to the service agents include asset issuing roles; business logic corresponding to the asset issuing role includes asset issuing logic;

the execution module 1303:

and invoking asset issuing logic corresponding to the determined asset management roles of the service agents in the intelligent contracts, and issuing the virtual resources to asset accounts of users of the target service.

In this embodiment, the transaction sender includes a service provider; the intelligent contract invoking transaction includes an account identification of the service provider; the asset management roles corresponding to the service providers include an asset update role; business logic corresponding to the asset update roles includes asset update logic;

the execution module 1303:

and invoking asset updating logic corresponding to the determined asset management roles of the service providers in the intelligent contracts to update unit revenue profit amounts corresponding to the virtual resources in the virtual resource pools.

In this embodiment, the transaction sender includes a user of the target service; the intelligent contract invoking transaction includes an account identification of the user; the asset management roles corresponding to the users comprise asset exchange roles; business logic corresponding to the asset redemption roles includes asset redemption logic;

the execution module 1303:

and invoking asset exchange logic corresponding to the determined asset management roles of the users in the intelligent contracts to exchange virtual resources to be exchanged, which are held by the asset accounts of the users.

In this embodiment, the virtual resource includes: and freezing the asset release guarantee provided by the service operator, and then releasing virtual resources in the blockchain.

In this embodiment, the target service includes a cultural entertainment service.

In this embodiment, the cultural entertainment service includes a movie service; the service operator comprises a sponsor of the movie service; the virtual resource is value anchored with at least some future box office revenues of the movie service.

In this embodiment, the cultural entertainment service includes a music service; the service operator comprises a copyright party of the music service; the virtual resource is value anchored with at least part of the future copyright revenues of the music service.

In this embodiment, the cultural entertainment service includes an online live service; the service operators comprise operators of the online live broadcast service; the virtual resource value anchors with at least a portion of the future appreciation benefits of the online live service.

In this embodiment, the cultural entertainment service includes an online video playing service; the service operator comprises an operator of the online video playing service; the virtual resource is value anchored with at least part of the advertising revenue in the future of the online video playing service.

In this embodiment, the blockchain is a coalition chain.

The implementation process of the functions and roles of each module in the above device is specifically shown in the implementation process of the corresponding steps in the above method, and will not be described herein again.

For the device embodiments, reference is made to the description of the method embodiments for the relevant points, since they essentially correspond to the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the modules illustrated as separate components may or may not be physically separate, and the components shown as modules may or may not be physical, i.e., may be located in one place, or may be distributed over a plurality of network modules. Some or all of the modules may be selected according to actual needs to achieve the purposes of the present description. Those of ordinary skill in the art will understand and implement the present invention without undue burden.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The terminology used in the one or more embodiments of the specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the specification. As used in this specification, one or more embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments of the present description. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.

The foregoing description of the preferred embodiment(s) is (are) merely intended to illustrate the embodiment(s) of the present invention, and it is not intended to limit the embodiment(s) of the present invention to the particular embodiment(s) described.

Claims

1. A resource management method based on a block chain is applied to node equipment in the block chain; wherein, the service operator corresponding to the target service issues virtual resources on the blockchain; the block chain is provided with an intelligent contract for managing the virtual resources; the execution logic corresponding to the contract code of the intelligent contract comprises a confirmation logic and a plurality of business logics respectively corresponding to different asset management operations; the method comprises the following steps:

Further calling business logic corresponding to the determined asset management role of the transaction sender in the intelligent contract to complete asset management operation corresponding to the business logic for the virtual resource;

wherein the transaction sender comprises an asset issuing user of a business operator; the intelligent contract invoking transaction comprises an account identifier of the asset issuing user and a freezing certificate of the asset issuing guarantee provided by the service operator; the asset management roles corresponding to the asset issuing users include asset issuing roles; business logic corresponding to the asset issuing roles includes credential verification logic and asset issuing logic;

and invoking business logic corresponding to the determined asset management role of the transaction sender in the intelligent contract to complete asset management operation corresponding to the business logic for the virtual resource, wherein the operation comprises the following steps:

2. The method of claim 1, the transaction sender comprising an asset management user of a business operator; the intelligent contract invoking transaction comprises account identifications of the asset management user and account identifications of a plurality of designated accounts holding virtual resources in the virtual resource pool; the asset management roles corresponding to the asset management users include an asset allocation role; business logic corresponding to the asset allocation role includes asset allocation logic;

invoking business logic corresponding to the determined asset management role of the transaction sender in the intelligent contract to complete asset management operation corresponding to the business logic for the virtual resource, wherein the operation comprises the following steps:

3. The method of claim 2, the number of designated accounts comprising contract accounts corresponding to the smart contract; the virtual resources held by the contract account are used for issuing to the user.

4. The method of claim 1, the transaction sender comprising a business agent; the intelligent contract invoking transaction comprises an account identifier of the service agent; the asset management roles corresponding to the service agents include asset issuing roles; business logic corresponding to the asset issuing role includes asset issuing logic;

5. The method of claim 1, the transaction sender comprising a service provider; the intelligent contract invoking transaction includes an account identification of the service provider; the asset management roles corresponding to the service providers include an asset update role; business logic corresponding to the asset update roles includes asset update logic;

6. The method of claim 1, the transaction sender comprising a user of the target service; the intelligent contract invoking transaction includes an account identification of the user; the asset management roles corresponding to the users comprise asset exchange roles; business logic corresponding to the asset redemption roles includes asset redemption logic;

7. The method of claim 1, wherein the virtual resource value anchors a predetermined proportion of the total amount of revenue in the future revenue of the target business.

8. The method of claim 1, the virtual resource comprising: and freezing the asset release guarantee provided by the service operator, and then releasing virtual resources in the blockchain.

9. The method of claim 1, the target service comprising a cultural entertainment service.

10. The method of claim 9, the cultural entertainment service comprising a movie service; the service operator comprises a sponsor of the movie service; the virtual resource is value anchored with at least some future box office revenues of the movie service.

11. The method of claim 9, the cultural entertainment service comprising a music service; the service operator comprises a copyright party of the music service; the virtual resource is value anchored with at least part of the future copyright revenues of the music service.

12. The method of claim 9, the cultural entertainment service comprising an online live service; the service operators comprise operators of the online live broadcast service; the virtual resource value anchors with at least a portion of the future appreciation benefits of the online live service.

13. The method of claim 9, the cultural entertainment service comprising an online video play service; the service operator comprises an operator of the online video playing service; the virtual resource is value anchored with at least part of the advertising revenue in the future of the online video playing service.

14. The method of claim 1, the blockchain being a coalition chain.

15. A resource management device based on a block chain is applied to node equipment in the block chain; wherein, the service operator corresponding to the target service issues virtual resources on the blockchain; the block chain is provided with an intelligent contract for managing the virtual resources; the execution logic corresponding to the contract code of the intelligent contract comprises a confirmation logic and a plurality of business logics respectively corresponding to different asset management operations; the device comprises:

the execution module is used for further calling business logic corresponding to the determined asset management role of the transaction sender in the intelligent contract to complete asset management operation corresponding to the business logic for the virtual resource;

the execution module:

16. The apparatus of claim 15, the transaction sender comprising an asset management user of a business operator; the intelligent contract invoking transaction comprises account identifications of the asset management user and account identifications of a plurality of designated accounts holding virtual resources in the virtual resource pool; the asset management roles corresponding to the asset management users include an asset allocation role; business logic corresponding to the asset allocation role includes asset allocation logic;

The execution module:

17. The apparatus of claim 16, the number of designated accounts comprising a contract account corresponding to the smart contract; the virtual resources held by the contract account are used for issuing to the user.

18. The apparatus of claim 15, the transaction sender comprising a business agent; the intelligent contract invoking transaction comprises an account identifier of the service agent; the asset management roles corresponding to the service agents include asset issuing roles; business logic corresponding to the asset issuing role includes asset issuing logic;

the execution module:

19. The apparatus of claim 15, the transaction sender comprising a service provider; the intelligent contract invoking transaction includes an account identification of the service provider; the asset management roles corresponding to the service providers include an asset update role; business logic corresponding to the asset update roles includes asset update logic;

The execution module:

20. The apparatus of claim 15, the transaction sender comprising a user of the target service; the intelligent contract invoking transaction includes an account identification of the user; the asset management roles corresponding to the users comprise asset exchange roles; business logic corresponding to the asset redemption roles includes asset redemption logic;

the execution module:

21. The apparatus of claim 15, the virtual resource value-anchored with a predetermined proportion of a total amount of revenue in the future of the target business.

22. The apparatus of claim 15, the virtual resource comprising: and freezing the asset release guarantee provided by the service operator, and then releasing virtual resources in the blockchain.

23. The apparatus of claim 15, the target service comprising a cultural entertainment service.

24. The apparatus of claim 23, the cultural entertainment service comprising a movie service; the service operator comprises a sponsor of the movie service; the virtual resource is value anchored with at least some future box office revenues of the movie service.

25. The apparatus of claim 23, the cultural entertainment service comprising a music service; the service operator comprises a copyright party of the music service; the virtual resource is value anchored with at least part of the future copyright revenues of the music service.

26. The apparatus of claim 23, the cultural entertainment service comprising an online live service; the service operators comprise operators of the online live broadcast service; the virtual resource value anchors with at least a portion of the future appreciation benefits of the online live service.

27. The apparatus of claim 23, the cultural entertainment service comprising an online video play service; the service operator comprises an operator of the online video playing service; the virtual resource is value anchored with at least part of the advertising revenue in the future of the online video playing service.

28. The device of claim 15, the blockchain being a coalition chain.

29. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to implement the method of any one of claims 1-14 by executing the executable instructions.

30. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the method of any of claims 1-14.