CN112200568B

CN112200568B - Block chain based account creation method and device and electronic equipment

Info

Publication number: CN112200568B
Application number: CN202011075467.4A
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: 2022-05-13
Anticipated expiration: 2040-10-09
Also published as: CN112200568A

Abstract

One or more embodiments of the present specification provide an account creation method, an account creation device, and an electronic device based on a blockchain, which are applied to a server; wherein, the service operator issues virtual resources on the block chain; the method comprises the following steps: receiving an asset account creation request sent by a client; wherein the asset account creation request comprises an account identifier of a user account of the client for the user to log in; the user account is a real-name account of the user; responding to the asset account creating request, generating a unique virtual identity for the user, and binding the account identity with the virtual identity; and creating an asset account corresponding to the virtual identity on the blockchain; wherein the first asset account is used to hold the virtual resource issued to a user.

Description

Block chain based account creation method and device 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 method and an apparatus for creating an account based on a blockchain, and an electronic device.

Background

The block chain technology, also called distributed ledger technology, is an emerging technology in which several computing devices participate in "accounting" together, and a complete distributed database is maintained together. The blockchain technology has been widely used in many fields due to its characteristics of decentralization, transparency, participation of each computing device in database records, and rapid data synchronization between computing devices.

Disclosure of Invention

The specification provides an account creation method based on a block chain, which is applied to a server side; wherein, the service operator issues virtual resources on the block chain; the method comprises the following steps:

receiving an asset account creation request sent by a client; wherein the asset account creation request comprises an account identifier of a user account of the client for the user to log in; the user account is a real-name account of the user;

responding to the asset account creating request, generating a unique virtual identity for the user, and binding the account identity with the virtual identity; and the number of the first and second groups,

creating an asset account corresponding to the virtual identity on the blockchain; wherein the first asset account is used to hold the virtual resource issued to a user.

The specification also provides an account creation device based on the block chain, which is applied to the server side; wherein, the service operator issues virtual resources on the block chain; the device comprises:

the first receiving module is used for receiving an asset account creating request sent by a client; wherein the asset account creation request comprises an account identifier of a user account of the client for the user to log in; the user account is a real-name account of the user;

the first binding module responds to the asset account creating request, generates a unique virtual identity for the user and binds the account identity with the virtual identity; and the number of the first and second groups,

the creating module is used for creating an asset account corresponding to the virtual identity on the block chain; wherein the first asset account is used to hold the virtual resource issued to a user.

This specification also proposes an electronic device including:

a processor;

a memory for storing processor-executable instructions;

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

The present specification also contemplates 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, a real-name account for holding the virtual resources can be created for the user on the blockchain, and the 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.

Drawings

FIG. 1 is a schematic diagram of a creation flow of an intelligent contract shown herein;

FIG. 2 is a schematic diagram illustrating the call flow of an intelligent contract shown in this specification;

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

FIG. 4 is a block chain based resource management system in accordance with an exemplary embodiment of the present specification;

FIG. 5 is a flow chart illustrating a method for block chain based resource management in an exemplary embodiment of the present specification;

FIG. 6 is a flow chart illustrating a method for blockchain based account creation in an exemplary embodiment of the present description;

fig. 7 is a flowchart illustrating a method for resource allocation based on a block chain according to an exemplary embodiment of the present specification;

fig. 8 is a flowchart illustrating another resource allocation method based on a blockchain according to an exemplary embodiment of the present disclosure;

fig. 9 is a flowchart illustrating another resource allocation method based on a blockchain according to an exemplary embodiment of the present disclosure;

fig. 10 is a flowchart illustrating another resource allocation method based on a blockchain according to an exemplary embodiment of the present disclosure;

fig. 11 is a flowchart illustrating another resource allocation method based on a block chain according to an exemplary embodiment of the present specification;

FIG. 12 is a diagram illustrating a hardware configuration of an electronic device in accordance with an exemplary embodiment of the present disclosure;

fig. 13 is a block diagram illustrating an account creation apparatus based on a blockchain according to an exemplary embodiment of the present specification.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent 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 certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). Furthermore, there may be a combination of the above types, such as private chain + federation chain, federation chain + public chain, and so on.

Among them, the most decentralized is the public chain. The public chain is represented by bitcoin and ether house, and participants (also called nodes in the block chain) joining the public chain can read data records on the chain, participate in transactions, compete for accounting rights of new blocks, and the like. Moreover, each node can freely join or leave the network and perform related operations.

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

A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; the nodes are authorized to join the network and form a benefit-related alliance, and block chain operation is maintained together.

Based on the basic characteristics of a blockchain, a blockchain is usually composed 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 according to the time stamps recorded in the blocks strictly.

The real data generated by the physical world can be constructed into a standard transaction (transaction) format supported by a block chain, then is issued to the block chain, the node equipment in the block chain performs consensus processing on the received transaction, and after the consensus is achieved, the node equipment serving as an accounting node in the block chain packs the transaction into a block and performs persistent evidence storage in the block chain.

The consensus algorithm supported in the blockchain may include:

the first kind of consensus algorithm, namely the consensus algorithm that the node device needs to contend for the accounting right of each round of accounting period; consensus algorithms such as Proof of Work (POW), Proof of equity (POS), Proof of commission rights (DPOS), etc.;

the second kind of consensus algorithm, namely the consensus algorithm which elects accounting nodes in advance for each accounting period (without competing for accounting right); for example, a consensus algorithm such as a Practical Byzantine Fault Tolerance (PBFT) is used.

In a blockchain network employing a first type of consensus algorithm, node devices competing for billing rights can execute a transaction upon receipt. One of the node devices competing for the accounting right may win in the process of competing for the accounting right in the current round, and become an accounting node. The accounting node may package the received transaction with other transactions to generate a latest block and send the generated latest block or a block header of the latest block to other node devices for consensus.

In the block chain network adopting the second type of consensus algorithm, the node equipment with the accounting right is agreed before accounting in the current round. Thus, the node device, after receiving the transaction, may send the transaction to the accounting node if it is not the accounting node of its own round. For the accounting node of the current round, the transaction may be performed during or before packaging it with other transactions to generate the latest block. After generating the latest block, the accounting node may send the latest block or a block header of the latest block to other node devices for consensus.

As described above, regardless of which consensus algorithm is used by the blockchain, the accounting node of the current round may pack the received transaction to generate the latest block, and send the generated latest block or the block header of the latest block to other node devices for consensus verification. If no problem is verified after other node equipment receives the latest block or the block header of the latest block, the latest block can be added to the tail of the original block chain, so that the accounting process of the block chain is completed. The transaction contained in the block may also be performed by other nodes in verifying the new block or block header sent by the accounting node.

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

For accounts in a blockchain, the account status of the account is usually maintained through a structure. When a transaction in a block is executed, the status of the account associated with the transaction in the block chain is also typically changed.

Taking etherhouses as an example, the structure of an account usually includes fields such as Balance, Nonce, Code and Storage. Wherein:

a Balance field for maintaining the 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 replay attack is effectively avoided;

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

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

Wherein, for the external account, the field values of the Code field and the Storage field shown above are both null values.

For most blockchain items, a Merkle tree is typically used; alternatively, the data is stored and maintained based on the data structure of the Merkle tree. Taking etherhouses as an example, the etherhouses use MPT tree (a Merkle tree variation) as a data organization form for organizing and managing important data such as account status, transaction information, and the like.

The Etherhouse designs three MPT trees, namely an MPT state tree, an MPT transaction tree and an MPT receipt tree, aiming at data needing to be stored and maintained in a block chain. In addition to the above three MPT trees, there is actually a Storage tree constructed based on the Storage content of the contract account.

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

The MPT transaction tree and the MPT receipt tree correspond to the blocks, namely each block has the MPT transaction tree and the MPT receipt tree. The MPT state tree is a global MPT tree, which does not correspond to a specific tile, but covers account state data of all accounts in the tile chain.

It should be noted that, each time a latest block is generated in the blockchain, after a transaction in the latest block is executed, the account status of the accounts (which may be an external account or a contract account) related to the executed transaction in the blockchain is usually changed;

for example, when a "transfer transaction" is completed in a block, the balances of the transferring party account and the transferring party account associated with the "transfer transaction" (i.e., the field values of the Balance fields of these accounts) are usually changed.

After the transaction in the latest block generated by the blockchain is completed, the node device needs to construct an MPT state tree according to the current account state data of all accounts in the blockchain because the account state in the current blockchain changes, so as to maintain the latest state of all accounts in the blockchain.

That is, each time a latest block is generated in the block chain and the account status in the block chain changes after the transaction in the latest block is executed, the node device needs to reconstruct an MPT status tree based on the latest account status data of all accounts in the block chain. In other words, each block in the block chain has a corresponding MPT state tree; the MPT status tree maintains the latest account status of all accounts in the blockchain after the transaction in the block is completed.

In practical applications, whether public, private, or alliance, it is possible to provide the functionality of a smart contract (smart contract). An intelligent contract on a blockchain is a contract on a blockchain that can be executed triggered by a transaction. An intelligent contract may be defined in the form of code.

Taking an Etherhouse as an example, a user is supported to create and call some complex logic in the Etherhouse network. The ethernet mill is a programmable blockchain, and the core of the ethernet mill is an ethernet mill virtual machine (EVM), and each ethernet mill node can run the EVM. The EVM is a well-behaved virtual machine through which various complex logic can be implemented. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, the EVM directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so the intelligent contract deployed on the blockchain may be bytecode.

After Bob sends a transaction (transaction) containing information to create a smart contract to the ethernet network, each node may perform the transaction in the EVM, as shown in fig. 1. In fig. 1, the From field of the transaction is used To record the address of the account initiating the creation of the intelligent contract, the contract code stored in the field value of the Data field of the transaction may be byte code, and the field value of the To field of the transaction is a null account. After the nodes reach the agreement through the consensus mechanism, the intelligent contract is successfully created, and the follow-up user can call the intelligent contract.

After the intelligent contract is established, a contract account corresponding to the intelligent contract appears on the block chain, and the block chain has a specific address; for example, "0 x68e12cf284 …" in each node in fig. 1 represents the address of the contract account created; the contract Code (Code) and account store (Storage) will be maintained in the account store for that contract account. The behavior of the intelligent contract is controlled by the contract code, while the account storage of the intelligent contract preserves the state of the contract. In other words, an intelligent contract causes a virtual account to be created on a blockchain that includes contract code and account storage.

It was mentioned earlier that the Data field containing the transaction that created the intelligent contract holds what may be the bytecode of the intelligent contract. A bytecode consists of a series of bytes, each of which can identify an operation. Based on the multiple considerations 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, the high-level language may employ a language such as Solidity, Serpent, LLL, and the like. For intelligent contract code written in a high-level language, the intelligent contract code can be compiled by a compiler to generate byte codes which can be deployed on a blockchain.

Taking the Solidity language as an example, the contract code written by it is very similar to a Class (Class) in the object-oriented programming language, and various members including state variables, functions, function modifiers, events, etc. can be declared in one contract. A state variable is a value permanently stored in an account Storage (Storage) field of an intelligent contract to save the state of the contract.

As shown in FIG. 2, still taking the Etherhouse as an example, after Bob sends a transaction containing the information of the calling intelligent contract to the Etherhouse network, each node can execute the transaction in the EVM. In fig. 2, the From field of the transaction is used for recording the address of the account initiating the intelligent contract call, the To field is used for recording the address of the intelligent contract called, and the Data field of the transaction is used for recording the method and parameters for calling the intelligent contract. After invoking the intelligent 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 block link point (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, and all execution records and data are stored on the blockchain, so that after the transaction is executed, transaction certificates which cannot be tampered and lost are stored on the blockchain.

A schematic diagram of creating an intelligent contract and invoking the intelligent contract is shown in fig. 3. An intelligent contract is created in an Ethernet workshop and needs to be subjected to the processes of compiling the intelligent contract, changing the intelligent contract into byte codes, deploying the intelligent contract to a block chain and the like. The intelligent contract is called in the Ethernet workshop, a transaction pointing to the intelligent contract address is initiated, the EVM of each node can respectively execute the transaction, and the intelligent contract code is distributed and operated in the virtual machine of each node in the Ethernet workshop network.

The event mechanism of the intelligent contract is a mode for the interaction between the intelligent contract and the out-of-chain entity. For intelligent contracts deployed on blockchains, direct interaction with out-of-chain entities is generally not possible; for example, the intelligent contract cannot generally send the call result of the intelligent contract to the call initiator of the intelligent contract point to point after the call is completed.

The call results (including intermediate results and final call results) generated by the intelligent contract in the call process are usually recorded in the form of events (events) to the transaction log (transaction logs) of the transaction that called the intelligent contract, and stored in the storage space of the node device. The entity outside the chain which needs 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, in the case of an Etherhouse, the transaction log will eventually be stored in the MPT receipt tree described above as part of the receipt (receipt) of the transaction pen transaction that invoked the smart contract. And the entity outside the chain interacting with the intelligent contract can monitor the transaction receipts stored in the storage space of the node device on the MPT receipt tree and acquire the events generated by the intelligent contract from the monitored transaction receipts.

The intelligent contracts deployed on the blockchains can only reference data contents stored on the blockchains generally; in practical applications, for some complex business scenarios implemented based on the intelligent contract technology, the intelligent contract may need to refer to some external data on the data entities outside the chain.

In this scenario, the intelligent contract deployed on the blockchain may refer to data on the data entities outside the chain through the Oracle prediction machine, thereby implementing data interaction between the intelligent contract and the data entities in the real world. Data entities outside the chain may include, for example, centralized servers or data centers deployed outside the chain, and so on.

It should be noted that the cross-link relay is used to connect two block chains, and the Oracle are used to connect the Oracle ora.

In practical application, when a predicting machine is deployed for an intelligent contract on a block chain, a predicting machine intelligent contract corresponding to the predicting machine can be deployed on the block chain; the intelligent contract of the prediction machine is used for maintaining external data sent to the intelligent contract on the block chain by the prediction machine; for example, external data sent by the predictive machine to the smart contract on the blockchain may be stored in the account storage space of the predictive machine smart contract.

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

It should be noted that, when sending external data to the smart contract on the blockchain, the prediction engine may use an active sending method or a passive sending method.

In one implementation, the data entity outside the chain may send external data to be provided to the target intelligent contract to the intelligent contract of the language prediction machine after signing by using the private key of the language prediction machine; for example, in time, the signed external data may be sent to the intelligent contract of the prediction machine in a periodic sending manner;

the intelligent contract of the language predicting machine can maintain a CA (certificate authority) certificate of the language predicting machine, after external data sent by a data entity outside a chain is received, a signature of the external data can be verified by using a public key of the language predicting machine maintained in the CA certificate, and after the signature passes, the external data sent by the data entity outside the chain is stored in an account storage space of the intelligent contract of the language predicting machine.

In another implementation, when a target intelligent contract on a blockchain is called, if external data required by the target intelligent contract is not read from an account storage space of the intelligent contract of the language predictive controller, the intelligent contract of the language predictive controller may interact with the language predictive controller by using an event mechanism of the intelligent contract, and the language predictive controller sends the external data required by the target intelligent contract to the account storage space of the intelligent contract of the language predictive controller.

For example, when a target intelligent contract on a blockchain is called, if external data required by the target intelligent contract is not read from an account storage space of the intelligent contract of the language predictive machine, the intelligent contract of the language predictive machine can generate an external data acquisition event, record the external data acquisition event into a transaction log of the transaction calling the intelligent contract, and store the transaction log into a storage space of a node device; the predicting machine can monitor a transaction log generated by the predicting machine intelligent contract stored in the storage space of the node equipment, respond to the monitored external data acquisition event after monitoring the external data acquisition event in the transaction log, and send the external data required by the target intelligent contract to the predicting machine intelligent contract.

Referring to fig. 4, fig. 4 is a schematic diagram illustrating a resource management system based on a block chain according to an exemplary embodiment of the present disclosure.

In the resource management system based on the blockchain as shown in fig. 4, in addition to the blockchain, a server that establishes a connection with the node devices in the blockchain and a client corresponding to the service operator (i.e., a client used by the service operator) may be further included, and a plurality of clients that establish a connection with the server. The plurality of clients establishing connection with the server may include a client corresponding to the service provider (i.e., a client used by the service provider), a client corresponding to the service broker (i.e., a client used by the service broker), and a client corresponding to a user to which the service is directed (i.e., a client used by the user); the server may include a server corresponding to an operator of the blockchain (i.e., a server used by the operator of the blockchain).

The client may be deployed on an electronic device, where the electronic device may be a server, a computer, a mobile phone, a tablet device, a notebook computer, a palmtop computer (PDAs), or the like; the server can also be deployed on an electronic device, and the electronic device can be a server, a computer, or the like; the electronic device added into the block chain as the node device can be a server, a computer, a mobile phone, a tablet device, a notebook computer, a palm computer and the like; this is not limited by the present description.

In practical applications, the services may include cultural entertainment services, such as: movie services, music services, online live broadcast services, online video playback services, and the like.

Taking a movie service as an example, a movie may 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 showing service of the movie to the user, the service agent may include an agent that acts on the sale of movie tickets corresponding to the movie theater and the movie, and the user may include a user who purchases movie tickets corresponding to the movie theater and the movie.

Taking a music service as an example, a song can be regarded as a service; for the service, the service operator may include a copyright owner of the song, the service provider may include an operator of an APP (Application) providing a playing service of the song to the user, the service agent may include an agent acting on purchase of a playing right corresponding to the APP and the song (e.g., purchase of a membership of the APP, purchase of a music album containing the song, etc.), and the user may include a user purchasing a playing right corresponding to the APP and the song.

Taking an online live broadcast 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 broadcast room, the service provider may include an operator that displays the APP of the live broadcast room to the user, the service broker may include a broker that brokers a recharge of the appreciation balance corresponding to the live broadcast room, and the user may include a user that recharges the appreciation balance corresponding to the live broadcast room.

Taking the online video playing service as an example, an online video set (e.g., an online video set of a movie or a television show, an online video set of a variety program, etc.) may 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 that presents an APP of the online video set to the user, the service broker may include a broker that brokers placement of advertisements corresponding to the online video set, and the user may include a user that views advertisements corresponding to the online video set.

In order to encourage users to consume a certain service (for example, purchase movie tickets, purchase playing rights of songs, enjoy in live broadcast, watch advertisements in online videos, etc.), and to promote the service to other users, a service operator may issue virtual resources corresponding to the service on the blockchain, and issue the virtual resources corresponding to the service to users who have consumed or promoted the service through asset accounts created for the users on the blockchain.

In one embodiment, the virtual resource corresponding to the service may be value-anchored to a revenue profit amount that is a preset proportion of the total revenue profit amount of the service in the future. The preset ratio may be preset by a service operator of the service.

Taking a movie service as an example, the virtual resource may be value anchored with at least a portion of the box office revenue for the movie service in the future.

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

Taking the live online service as an example, the virtual resource may be value-anchored with at least part of the future reward revenue of the live online service.

Taking an online video playing service as an example, the virtual resource may be value anchored with at least part of the future advertising revenue of the online video playing service.

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

Specifically, the node device in the block chain may freeze an asset issuance deposit provided by a service operator of the service, and after the freezing of the asset issuance deposit is completed, invoke asset issuance logic deployed in an intelligent contract on the block chain, create a preset number of virtual resources, form a virtual resource pool from the created virtual resources, and issue the formed virtual resource pool to a contract account corresponding to the intelligent contract, where the virtual resource pool is held 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 block chain for the service. The preset number may be preset by a service operator of the service.

Taking a movie service as an example, suppose the box office income of the movie service at a certain future time 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 deposit provided by the exporter of the movie service, and after the freezing of the asset issuance deposit is completed, invoke asset issuance logic in the intelligent contract deployed on the blockchain, create 10 ten thousand virtual resources for the movie service, where the value of each virtual resource is 1000 ten thousand units by 1%/10 ten thousand units by 1 unit, form a virtual resource pool from 10 ten thousand units of the virtual resource with a value of 1 unit, and issue the formed virtual resource pool to a contract account corresponding to the intelligent contract, where the virtual resource pool is held by the contract account corresponding to the intelligent contract.

Subsequently, if the box office revenue 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.

It should be noted that, when the total amount of the asset issuance deposit provided by the service operator of the service is less than 20% of the total value of all the issued virtual assets, the service operator can supplement the asset issuance deposit, and the total amount of the asset issuance deposit is not less than 30% of the total value of all the issued virtual assets.

Continuing with the movie service example described above, assuming that the asset issuance guarantee fund provided by the offerer of the movie service is 3 ten thousand dollars, when the value of each virtual resource is updated to 2 dollars, since 2 dollars/10 million dollars 20% is 4 ten thousand dollars and is greater than the asset issuance guarantee fund currently provided by the offerer of the movie service, the offerer of the movie service needs to supplement the asset issuance guarantee fund to 2 dollars/10 million dollars 30% is 6 ten thousand dollars.

In one embodiment, the server may be a baas (blockchain as a service) platform for managing the block chain.

In practical applications, multiple block chains may be deployed and managed by the Baas platform. In this case, when creating a corresponding asset account for a user, the corresponding asset account may be created for the user on the plurality of blockchains, respectively.

In one embodiment shown, the blockchain may be a federation chain; the federation members of the federation chain may include an operator of the federation chain corresponding to the service end, and a service operator of the service.

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

In conjunction with the resource management system based on the block chain as shown in fig. 4, the above resource management method based on the block chain may be applied to the node devices in the block chain as shown in fig. 4; the resource management method based on the block chain can comprise the following steps:

step 501, receiving an intelligent contract calling transaction corresponding to an intelligent contract; wherein the smart contract invocation transaction includes an account identification of a transaction sender;

step 502, responding to the intelligent contract invoking transaction, invoking confirmation logic in the intelligent contract, and determining the 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;

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

In this embodiment, an intelligent contract for managing the virtual resource may be deployed on the block chain. The execution logic corresponding to the contract code of the intelligent contract comprises confirmation logic and various business logics respectively corresponding to different asset management operations.

For a certain service (referred to as a target service), a service operator of the target service, a service provider of the target service, a service agent of the target service, a client corresponding to a user of the target service, and the server may all send an intelligent contract invocation transaction corresponding to the intelligent contract to a node device in the block chain. Wherein the smart contract invocation transaction may include an account identification of a transaction sender sending the smart contract invocation transaction.

In this embodiment, when receiving an intelligent contract invocation transaction corresponding to the intelligent contract, a node device in the block chain may invoke a confirmation logic in the intelligent contract in response to the intelligent contract invocation transaction, and determine an asset management role of the transaction sender based on an account identifier in the intelligent contract invocation 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 respectively correspond to different business logics in the intelligent contract.

In this embodiment, after determining the asset management role of the transaction sender, the node device in the block chain may further invoke a service logic corresponding to the asset management role of the transaction sender in the intelligent contract, and complete an asset management operation corresponding to the service logic for the virtual asset issued by the service operator on the block chain.

In one embodiment shown, the transaction sender may comprise an asset issuing user of a service operator; the intelligent contract invoking transaction can comprise an account identification of the asset issuing user and a frozen certificate of the asset issuing deposit provided by the service operator; the asset management role corresponding to the asset issuing user may include an asset issuing role; business logic corresponding to the asset issuance role can include credential verification logic and asset issuance logic.

In this case, the node device in the block chain may invoke a credential check logic corresponding to the determined asset management role (i.e., asset issuance role) of the asset issuance user in the intelligent contract, and perform validity check on the frozen credential; and if the validity check of the frozen certificate passes, further calling an 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 comprise an asset management user of a service operator; the intelligent contract invoking transaction may include an account identifier of the asset management user and account identifiers of a plurality of designated accounts holding the virtual resources in the virtual resource pool; the asset management roles corresponding to the asset management user may include an asset allocation role; the business logic corresponding to the asset allocation role can include asset allocation logic.

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

Further, in one illustrated embodiment, the designated accounts may include a contract account corresponding to the intelligent contract; wherein the virtual resource held by the contract account is used for issuing the virtual resource to the user.

In practical applications, the designated accounts may also include asset accounts of partners (e.g., partners) participating in the target 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, the transaction sender may include a service agent; the intelligent contract invoking transaction may include an account identifier of the service agent; the asset management role corresponding to the service broker may include an asset issuance role; the business logic corresponding to the asset issuance role may include asset issuance logic.

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

It should be noted that the virtual resource issued to the user is a virtual resource held by a contract account corresponding to the intelligent contract.

In one embodiment shown, the transaction sender may include a service provider; the intelligent contract invoking transaction may include an account identifier of the service provider; the asset management role corresponding to the service provider may include an asset update role; the business logic corresponding to the asset update role can include asset update logic.

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

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

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

In this embodiment, by defining an asset role in an intelligent contract deployed on a blockchain, the invocation authority of 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 method for creating an account based on a blockchain according to an exemplary embodiment of the present disclosure.

In conjunction with the resource management system based on the blockchain as shown in fig. 4, the above account creation method based on the blockchain may be applied to the server as shown in fig. 4; the account creating method based on the block chain can comprise the following steps:

step 601, receiving an asset account creation request sent by a client; wherein the asset account creation request comprises an account identifier of a user account of the client for the user to log in; the user account is a real-name account of the user;

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

step 603, an asset account corresponding to the virtual identity is created on the block chain; wherein the first asset account is used to hold the virtual resource issued to a 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 of the client into which the user logs; the user account may specifically be a real-name account of the user.

For example, since a user's payment account is typically a real-name account 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 receiving the asset account creation request sent by the client, the server may generate a unique virtual identity for the user in response to the asset account creation request, and bind an account identity in the asset account creation request (i.e., an account identity of a real-name account of the user) with the virtual identity.

For example, when the virtual identity is generated for the user, hash calculation may be performed on information such as a timestamp corresponding to the current time, a branch base ID and a branch table ID of a database storing real name information of the user, and a version number of a generation rule of the virtual identity, and the calculated hash value may be 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, according to a coding rule preset by a technician, coding a character string obtained by splicing the information, and using the coded character string as the virtual identity of the user; this is not limited by the present description.

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

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

In an 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 obtained, 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 inquired, the account identifications in the asset account creation request and the virtual identity generated for the user can be bound, and meanwhile, the inquired other account identifications and the virtual identity generated for the user are also bound.

In an embodiment shown, the user may also initiate an asset account binding request through the client, and the client sends the asset account binding request to the server. The asset account binding request may include identity information of the user (e.g., information that may be used to indicate the identity of the user, such as a mobile phone number, a license plate number, etc., of the user).

When receiving the asset account binding request sent by the client, the server may respond to the asset account binding request, invoke an account binding logic in an intelligent contract deployed on the blockchain and used for managing the virtual resource, bind the identity information in the asset account binding request with an asset account corresponding to the 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 may be stored in the memory space of the intelligent contract.

In an embodiment shown, 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 check corresponding to the user identity indicated by the identity information passes, so that a certificate passing the identity check can be issued to the client, and the certificate indicates that the identity check 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 credential, and send the asset account binding request to the server.

When receiving the asset account binding request sent by the client, the server may respond to the asset account binding request, invoke the intelligent contract deployed on the block chain, perform validity check on the credential 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 credential passes.

In one embodiment, the certification authority may be a third-party certification authority. When the third-party certification authority serving as the certification side issues the certificate to the client, the digital signature can be performed based on the private key of the third-party certification authority.

In this case, when receiving the asset account binding request sent by the client, the server may invoke the intelligent contract deployed on the block chain in response to the asset account binding request, and verify the digital signature of the credential in the asset account binding request based on the public key maintained by the intelligent contract and corresponding to the private key of the third-party certificate authority; if the verification is passed, the validity check 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 an embodiment shown, in order to implement the binding of the identity information in the asset account binding request and the asset account corresponding to the virtual identity generated for the user, and store the binding relationship in the blockchain, the server may first determine whether the asset account corresponding to the identity information in the asset account binding request is already created in 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 may 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 first create an asset account corresponding to the identity information in the asset account binding request on the blockchain, then bind the created asset account corresponding to the identity information in the asset account binding request with an asset account corresponding to the virtual identity generated for the user, and store the binding relationship in the blockchain.

It should be noted that the asset account corresponding to the identity information in the asset account binding request may be a blockchain account for holding the 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 intelligent contract deployed on the blockchain.

In the embodiment, a real-name account for holding the virtual resource can be created for the user on the blockchain, and the 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 resource allocation method based on a block chain according to an exemplary embodiment of the present disclosure.

In conjunction with the resource management system based on the block chain shown in fig. 4, the resource issuing method based on the block chain may be applied to the node device in the block chain shown in fig. 4; the resource distribution method based on the block chain can comprise the following steps:

step 701, receiving a first transaction for issuing a virtual resource 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 block chain, invoking a resource issuing logic in the intelligent contract, and issuing a virtual resource allocated to the user from a preset virtual resource pool 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 a resource transfer logic in the intelligent contract, and transferring the virtual resource 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 may be deployed on the blockchain.

In addition, referring to the embodiment shown in fig. 6, for a certain 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 block chain; alternatively, an asset account corresponding to the user's identity information (referred to as a temporary asset account) 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 broker may initiate a request for issuing a virtual resource to the user through a corresponding client, so that a transaction (referred to as a first transaction) for issuing the virtual resource 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 sent to a node device in the blockchain. Wherein the first transaction may include identity information of the user.

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

For example, suppose that a service operator of a certain movie initiates a transaction for issuing 10 virtual resources to a certain user based on the mobile phone number of the user through a corresponding client. In this case, the client may send the transaction to the node device in the blockchain, so that when the node device in the blockchain receives the transaction sent by the client, in response to the transaction, it is first determined whether a temporary asset account corresponding to the mobile phone number of the user has been created on the blockchain; if yes, then resource issuing logic in the intelligent contract deployed on the blockchain can be further invoked subsequently, the 10 virtual resources allocated to the user are issued from the virtual asset pool to a 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, in response to the first transaction, the node device in the blockchain may first determine whether a user asset account corresponding to the virtual identity of the user and the identity information in the first transaction are already bound (i.e., determine whether a 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 yes, resource transfer logic in the intelligent contract deployed on the blockchain can be further invoked subsequently, so that the virtual resource held by the temporary asset account corresponding to the identity information in the first transaction is 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 resource allocated to the user.

Continuing with the above example as an example, assuming that it is determined that the mobile phone number of the user is already bound to the user asset account corresponding to the virtual id of the user, the resource transfer logic in the intelligent contract deployed on the blockchain may be further invoked to transfer the 10 virtual resources held by the temporary asset account corresponding to the mobile phone number of the user to the user asset account corresponding to the virtual id of the user, and the 10 virtual resources allocated to the user are continuously held by the user asset account corresponding to the virtual id of the user.

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

If the temporary asset account corresponding to the identity information in the first transaction has been created on the blockchain, a resource issuing logic in the intelligent contract may be further invoked, allocating a virtual resource for the user from a virtual resource pool for maintaining the virtual resource issued by the service operator on the blockchain, and issuing the virtual resource allocated for the user from the virtual resource pool to the temporary asset account corresponding to the identity information in the first transaction, where the temporary asset account corresponding to the identity information in the first transaction holds the virtual resource allocated for the user.

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

In one embodiment, in order to determine whether the user asset account corresponding to the identity information in the first transaction and the virtual identity of the user has been bound, a second determination logic disposed in the intelligent contract on the blockchain may be invoked to query the binding relationship stored in the blockchain to determine whether the user asset account corresponding to the identity information in the first transaction and the virtual identity of the user has been bound.

If the identity information in the first transaction is bound with the user asset account corresponding to the virtual identity of the user, resource transfer logic in the intelligent contract can be further invoked to transfer the virtual resources 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 resources allocated to the user.

If the identity information in the first transaction and the user asset account corresponding to the virtual identity of the user are not bound, it can be considered that the transfer of the virtual resources to the user asset account is not required currently.

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

The node device in the blockchain, upon receiving the second transaction, may invoke third determination logic in the smart contract deployed on the blockchain to determine whether a temporary asset account corresponding to the identity information in the second transaction has been created on the blockchain in response to the second transaction.

If the temporary asset account corresponding to the identity information in the second transaction has been created on the blockchain, an account binding logic in the intelligent contract may 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 store the binding relationship 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 considered that there is no binding of identity information for the user asset account corresponding to the virtual identity of the user currently.

It should be noted that, 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 block chain, 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 block chain.

In this case, the second transaction may include the credential in addition to the identity information of the user; that is, the client or the server establishing 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 receiving the second transaction, the node device in the blockchain may call, in response to the second transaction, a check logic in the intelligent contract deployed on the blockchain, perform validity check on the credential 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 check on the credential passes.

In this case, when receiving the second transaction, the node device in the blockchain may invoke, in response to the second transaction, check logic in the intelligent contract deployed on the blockchain, and verify the digital signature of the credential in the second transaction based on a public key maintained by the intelligent contract and corresponding to the private key of the third-party certificate authority; if the verification is passed, the validity check of the certificate in the second transaction can be determined to pass, 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 above technical solution, a temporary asset account corresponding to user identity information is created on a blockchain, so that a service operator can issue virtual assets to a user based on the user identity information, and when the user authorizes to associate an individual identity with a user asset account corresponding to a VID of the user created on the blockchain, virtual resources held by the temporary asset account can be further transferred to the user asset account to complete resource issue, thereby avoiding a problem that the service operator cannot know the account identity of the user asset account and virtual resource issue fails.

Referring to fig. 8, fig. 8 is a flowchart illustrating another resource allocation method based on a block chain according to an exemplary embodiment of the present disclosure.

In conjunction with the resource management system based on the block chain shown in fig. 4, the resource issuing method based on the block chain may be applied to the server shown in fig. 4; the resource distribution method based on the block chain can comprise the following steps:

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

step 802, performing data verification on the consumption record;

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

For a certain service (referred to as a target service), a service provider of the target service, a service agent of the target service, or a client corresponding to a user of the target service may send, to the server, a consumption record corresponding to the target service, and a user identifier of a promoting user corresponding to the consumption record (for example, an account identifier of a user account of a client login of the promoting user, a mobile phone number of the promoting user, a license plate number of the promoting user, and the like).

In an embodiment shown, the consumption record corresponding to the target service may be sent to the server through the corresponding client by one or more of the service provider, the service broker, or the user.

Taking the promotion of a certain movie shown in a certain movie theater as an example, the promoting user can share the ticket purchasing link corresponding to the movie theater and the movie with the promoted user. Wherein the ticketing link may include a user identification of the promoting user. The promoted user can enter a ticket purchasing interface through the ticket purchasing link to purchase movie tickets corresponding to the movie theater and the movie through the ticket purchasing interface. After the ticket purchasing is completed, the client corresponding to the promoted user can generate a consumption record, and send the user identifier of the promoted user acquired from the ticket purchasing link and the consumption record to the server.

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

In this embodiment, when receiving the consumption record corresponding to the target service and the user identifier of the popularization user corresponding to the consumption record, the server may perform data verification on the consumption record, and when the data verification on the consumption record passes, further invoke a resource issuing logic in the intelligent contract deployed on the block chain, allocate a virtual resource to the popularization user from a virtual resource pool used for maintaining the virtual resource issued by the service operator on the block chain, and issue the virtual resource allocated to the popularization user from the virtual resource pool to an asset account of the popularization user, where the asset account of the popularization user holds the virtual resource allocated to the popularization user.

In practical applications, the consumption record may be subjected to data verification by a common data verification method, for example: the consumption record may be digitally signed and the digital signature of the consumption record may be subsequently validated.

In an illustrated embodiment, the user identifier of the promoting user may include identity information of the promoting user.

In this case, referring to the embodiment shown in fig. 7, before invoking the resource issuance logic in the intelligent contract deployed on the blockchain, the server may determine whether an asset account corresponding to the identity information of the promotion user has been created on the blockchain.

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

Specifically, the server may invoke a first determination logic in the above-mentioned intelligent contract deployed on the blockchain, and determine whether an asset account corresponding to the identity information of the promotion user has been created on the blockchain.

If the asset account corresponding to the identity information of the promotion user is created on the blockchain, a resource distribution logic in the intelligent contract can be further called, virtual resources are distributed to the promotion user from a virtual resource pool used for maintaining the virtual resources published by the service operator on the blockchain, the virtual resources distributed to the promotion user are distributed to the asset account corresponding to the identity information of the promotion user from the virtual resource pool, and the asset account corresponding to the identity information of the promotion user holds the virtual resources distributed to the promotion user.

If the asset account corresponding to the identity information of the promotion user is not established on the block chain, an account establishing logic in the intelligent contract can be further invoked, the asset account corresponding to the identity information of the promotion user is established on the block chain, after the asset account is established, a resource issuing logic in the intelligent contract is further invoked, virtual resources are distributed to the promotion user from a virtual resource pool used for maintaining the virtual resources distributed on the block chain by the service operator, the virtual resources distributed to the promotion user are distributed to the asset account corresponding to the identity information of the promotion user from the virtual resource pool, and the asset account corresponding to the identity information of the promotion user holds the virtual resources distributed to the promotion user.

In one illustrated embodiment, referring to the embodiment shown in fig. 6, on one hand, a unique virtual id may be generated for the promoting user, and an asset account (i.e., user asset account) corresponding to the virtual id of the promoting user may be created on the blockchain; on the other hand, the asset account (i.e., the temporary asset account) corresponding to the identity information of the promotion user may be specifically a temporary account created by the intelligent contract deployed on the block chain.

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

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

If the identity information of the promotion user is bound with the user asset account corresponding to the virtual identity of the promotion user, resource transfer logic in the intelligent contract can be further called, after the virtual resource distribution of the temporary asset account corresponding to the identity information of the promotion user is completed, the virtual resource held by the temporary asset account corresponding to the identity information of the promotion user is transferred to the user asset account corresponding to the virtual identity of the promotion user, and the user asset account corresponding to the virtual identity of the promotion user continues to hold the virtual resource distributed to the user.

If the identity information of the promotion user and the user asset account corresponding to the virtual identity of the promotion user are not bound, it can be considered that the virtual resource transfer is not required for the user asset account currently.

In an illustrated embodiment, the user identifier of the promoting user may include a virtual identity of the promoting user.

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

In one embodiment, if a refund process corresponding to the consumption record is executed for the consumption record, the service provider, the service broker, or the client corresponding to the user may transmit the refund record corresponding to the consumption record to the server.

When receiving the refund record corresponding to the consumption record, the server may perform data verification on the refund record, and when the data verification on the refund record passes, further invoke resource transfer logic deployed in the intelligent contract on the block chain, and re-transfer the virtual resource, which is held by the asset account of the promotion user and allocated to the promotion user for the consumption record, to the virtual resource pool.

In an illustrated embodiment, the contract account corresponding to the intelligent contract deployed on the blockchain may maintain a state machine corresponding to each virtual resource allocated to the popularization user. Wherein the state machine comprises a pre-allocation state and an allocation success state; the initial state of the state machine is the pre-allocation state.

In this case, for a certain virtual resource allocated to the popularization user, it may be determined whether the target task corresponding to the virtual resource has been completed; if the target task is completed, state maintenance logic in the intelligent contract can be further called, and the state corresponding to the virtual resource held by the asset account of the promotion user is switched from the pre-allocation state to the allocation success state.

It should be noted that, the user cannot exchange the virtual resources in the pre-allocated state as the virtual resources to be exchanged; that is, the user can only perform the redemption of the virtual resource for the virtual resource in the successful allocation state.

In an embodiment shown in the above, after the data of the consumption record is verified, the server may further store the consumption record in a local service database, and obtain a state corresponding to the virtual resource allocated to the popularization user for the consumption record maintained by a contract account corresponding to the intelligent contract deployed on the block chain, 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, the consuming user corresponding to the consumption record of the target service can obtain the virtual resource issued by the service operator; on the other hand, the promotion 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 also be stimulated to actively promote the service for the target service, so that the promotion cost of the target service can be obviously reduced. In addition, when the virtual resources are simultaneously distributed to the consuming users and the popularizing users, the quantity of the virtual resources distributed to the popularizing users is larger than that of the consuming users, so that the users can be further encouraged 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 resource allocation method based on a block chain according to an exemplary embodiment of the present disclosure.

step 901, receiving a first intelligent contract calling transaction corresponding to the intelligent contract; the first intelligent contract invoking transaction comprises a consumption record corresponding to the target service and a user identifier of a promotion user corresponding to the consumption record;

step 902, responding to the first intelligent contract invoking transaction, invoking a first checking logic in the intelligent contract, and performing data checking on the consumption record;

step 903, responding to the data verification passing of the consumption record, further invoking a resource issuing logic in the intelligent contract, and issuing the virtual resources distributed to 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 block chain may receive an intelligent contract invoking transaction (referred to as a first intelligent contract invoking transaction) corresponding to the intelligent contract. The first intelligent contract invoking transaction may include a consumption record corresponding to the target service and a user identifier of the promoting user corresponding to the consumption record. Subsequently, the node device in the block chain may invoke a transaction in response to the first intelligent contract, invoke check logic (referred to as first check logic) in the intelligent contract, perform data check on the consumption record, and further invoke resource issuing logic in the intelligent contract deployed on the block chain when the data check on the consumption record passes, allocate a virtual resource to the popularization user from a virtual resource pool used for maintaining the virtual resource issued by the service operator on the block chain, and issue the virtual resource allocated to the popularization user from the virtual resource pool to an asset account of the popularization user, where the asset account of the popularization user holds the virtual resource allocated to the popularization user.

In this embodiment, the consumption record corresponding to the target service includes one or more of the following combinations: consumption records sent by the service agent side corresponding to the target service; consumption records 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 is value-anchored to the revenue profit amount of the target service at a preset ratio in the future revenue profit total amount.

In this embodiment, the virtual resources include: after the asset issuance guarantee fund provided by the service operator is frozen, the virtual asset is issued in the block chain;

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 block chain may also invoke an asset issuing logic in the intelligent contract in response to a prompt event that the freezing process of the asset issuing guarantee fund 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 block chain may further receive a second intelligent contract invocation transaction corresponding to the intelligent contract; wherein the second smart contract invocation transaction includes a refund record corresponding to the consumption record. Subsequently, the node device in the block chain may invoke a transaction in response to the second intelligent contract, invoke a second check logic in the intelligent contract, perform data verification on the refund record, and invoke a resource transfer logic in the intelligent contract when the data verification on the refund record passes, so as to transfer the virtual resource held by the asset account of the popularization user to the preset virtual resource pool.

In this embodiment, the contract account corresponding to the intelligent contract may maintain a state machine corresponding to the virtual resource allocated to the popularization user; wherein 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 block chain may further invoke a state maintenance logic in the intelligent contract in response to a prompt event that the target service is completed, and switch the virtual resource held by the asset account of the popularization user from a pre-allocation state to an allocation success state.

In this embodiment, the node device in the block chain may further store the consumption record in the block chain in response to the data check for the consumption record passing; and acquiring a state corresponding to the virtual resource distributed to the promotion user and maintained by the intelligent contract, and setting a corresponding state for the consumption record stored in the block chain based on the acquired state corresponding to the virtual resource.

It should be noted that, for a specific manner in which the node device in the block chain executes the steps 901 to 903, reference may be made to a specific manner in which the Baas platform executes the steps 801 to 803 in the resource distribution method based on the block chain as shown in fig. 8, and this description is not repeated herein.

In the above technical solution, on one hand, the consuming user corresponding to the consumption record of the target service can obtain the virtual resource issued by the service operator; on the other hand, the promotion 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 also be stimulated to actively promote the service for the target service, so that the promotion cost of the target service can be obviously reduced. In addition, when virtual resources are simultaneously distributed to the consuming users and the popularizing users, the quantity of the virtual resources distributed to the popularizing users is larger than that of the consuming users, so that the users can be further stimulated to popularize the services, and the popularization cost of the target services is reduced.

Referring to fig. 10, fig. 10 is a flowchart illustrating another resource allocation method based on a block chain according to an exemplary embodiment of the present disclosure.

In combination with the resource management system based on the block chain as shown in fig. 4, the resource issuing method based on the block chain may be applied to the server side as shown in fig. 4; the resource distribution method based on the block chain can comprise the following steps:

1001, receiving a consumption record corresponding to the target service, and user identifications of a consumption user and a promotion user corresponding to the consumption record;

step 1002, performing data verification on the consumption record;

step 1003, responding to the data verification passing aiming at the consumption record, calling a resource issuing logic in the intelligent contract, and respectively issuing the virtual resources distributed to the consumption user and/or the promotion user from a preset virtual resource pool to the asset account of the consumption user and/or the promotion user for holding.

For a certain service (referred to as a target service), a service provider of the target service, a service agent of the target service, or a client corresponding to a user of the target service may send, to the server, a consumption record corresponding to the target service, and user identifiers of a consuming user and a promoting user corresponding to the consumption record (for example, an account identifier of a user account of a user login client, a mobile phone number of the user, a license plate number of the user, and the like).

Taking the promotion of a certain movie shown in a certain movie theater as an example, the promoting user can share the ticket purchasing link corresponding to the movie theater and the movie with the promoted user. Wherein the ticketing link may include a user identification of the promoting user. The promoted user can be used as a consuming user to enter a ticket purchasing interface through the ticket purchasing link so as to purchase movie tickets corresponding to the movie theater and the movie through the ticket purchasing interface. After the ticket booking is completed, the client corresponding to the consuming user can generate a consuming record, and send the user identifier of the consuming user, the user identifier of the promotion user acquired from the ticket booking link, and the consuming record to the server.

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

Specifically, on one hand, a virtual resource may be allocated to the consuming user from the virtual resource pool, and the virtual resource allocated to the consuming user is issued from the virtual resource pool to an asset account of the consuming user, where the asset account of the consuming user holds the virtual resource allocated to the consuming user; on the other hand, the virtual resources can be allocated to the consuming user from the virtual resource pool, and the virtual resources allocated to the promoting user are distributed to the asset account of the promoting user from the virtual resource pool, and the asset account of the promoting user holds the virtual resources allocated to the promoting user.

In practical applications, virtual resources may be allocated only to the consuming users or the promoting users; or, virtual resources may be allocated to the consuming user and the promoting user at the same time.

It should be noted that, when allocating virtual resources to the consuming user and the promoting user at the same time, the number of virtual resources allocated to the promoting user is greater than the number of virtual resources allocated to the consuming user.

In one embodiment shown, the consumption record further comprises a timestamp corresponding to the moment of consumption. In this case, the amount of virtual resources allocated to the consuming user and/or the promoting user is inversely proportional to the magnitude of the time stamp 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 is), 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 smaller the amount 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 that the amount of virtual resources allocated to the consuming user and the amount of virtual resources allocated to the promoting user may be different.

The following specifically describes the step of allocating virtual resources to the popularization user, taking the allocation of virtual resources to the popularization user as an example.

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

If the asset account corresponding to the identity information of the promotion user is created on the blockchain, a resource distribution logic in the intelligent contract can be further called, virtual resources are distributed to the promotion user from a virtual resource pool used for maintaining the virtual resources distributed by the service operator on the blockchain, the virtual resources distributed to the promotion user are distributed to the asset account corresponding to the identity information of the promotion user from the virtual resource pool, and the asset account corresponding to the identity information of the promotion user holds the virtual resources distributed to the user.

If the asset account corresponding to the identity information of the promotion user is not created on the block chain, further invoking an account creation logic in the intelligent contract, creating the asset account corresponding to the identity information of the promotion user on the block chain, and after the asset account creation is completed, further invoking a resource distribution logic in the intelligent contract, distributing virtual resources for the promotion user from a virtual resource pool for maintaining the virtual resources distributed by the service operator on the block chain, distributing the virtual resources distributed for the promotion user from the virtual resource pool to the asset account corresponding to the identity information of the promotion user, wherein the asset account corresponding to the identity information of the promotion user holds the virtual resources distributed for the user.

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

When the server receives the refund record corresponding to the consumption record, data verification can be carried out on the refund record, when the data verification on the refund record passes, resource transfer logic deployed in the intelligent contract on the block chain is further called, virtual resources, which are held by the asset account of the consumption user and allocated to the consumption user according to the consumption record, are transferred to the virtual resource pool again, and virtual resources, which are held by the asset account of the popularization user and allocated to the popularization user according to the consumption record, are transferred to the virtual resource pool.

In an illustrated embodiment, the contract account corresponding to the intelligent contract deployed on the blockchain may maintain a state machine corresponding to each virtual resource allocated to the consuming user and the promoting user. Wherein the state machine comprises a pre-allocation state and an allocation success state; the initial state of the state machine is the 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 target task corresponding to the virtual resource has been completed; if the target task is completed, state maintenance logic in the intelligent contract can be further called, and the state corresponding to the virtual resource held by the asset account of the consuming user or the asset account of the popularizing user is switched from a pre-allocation state to an allocation success state.

It should be noted that, the user cannot exchange the virtual resources in the pre-allocated state as the virtual resources to be exchanged; that is, the user can only perform redemption of the virtual resource for the virtual resource in the allocation successful state.

In an embodiment shown in the above, after the data of the consumption record is verified, the server may further store the consumption record in a local service database, and obtain a state, corresponding to the 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 block chain, 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 an embodiment shown, the service provider of the target service may send revenue data corresponding to the target service to the server through the client corresponding to the service provider.

When the server receives the revenue data sent by the client, the server can check the revenue data, and when the data check for the revenue data passes, further calling the calculation logic in the intelligent contract deployed in the block chain, updating the revenue profit total amount of the target service based on the revenue data, and updating the revenue profit total amount of the target service based on the updated revenue profit total amount of the target service, and the total issued amount of the virtual resources in the virtual resource pool for maintaining the virtual resources issued by the service operator on the blockchain, further calculating the unit revenue profit amount corresponding to the virtual resources in the virtual resource pool (for example, the unit revenue amount is the total revenue amount/the total issued amount of the virtual resources), and maintaining the calculated profit amount of the unit in the contract account corresponding to the intelligent contract.

In an embodiment shown, a 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 amount of virtual resources to be redeemed (i.e., the amount of virtual resources held by the user's asset account).

When receiving the resource exchange request sent by the client, the server may invoke resource exchange logic deployed in the intelligent contract on the block chain in response to the resource exchange request, 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 is the unit revenue amount).

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

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

In this case, after the transfer processing is completed, the server may further invoke asset verification logic deployed in the intelligent contract on the block chain, and perform verification processing on the virtual resource to be redeemed held in the asset account corresponding to the account identifier, for example: and removing the virtual resource to be exchanged from the asset account corresponding to the account identification.

Referring to fig. 11, fig. 11 is a flowchart illustrating another resource allocation method based on a block chain according to an exemplary embodiment of the present disclosure.

step 1101, receiving a first intelligent contract invoking transaction corresponding to the intelligent contract; the first intelligent contract invoking transaction comprises a consumption record corresponding to the target service, and user identifications of a consumption user and a promotion user corresponding to the consumption record;

step 1102, responding to the first intelligent contract invoking transaction, invoking a first checking logic in the intelligent contract, and performing data checking on the consumption record;

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

In this embodiment, the node device in the block chain may receive an intelligent contract invoking transaction (referred to as a first intelligent contract invoking transaction) corresponding to the intelligent contract. The first intelligent contract invoking transaction may include a consumption record corresponding to the target service, and user identifiers of a consuming user and a promoting 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 check logic (referred to as first check logic) in the intelligent contract, perform data check on the consumption record, and further invoke resource issuing logic in the intelligent contract deployed on the blockchain when the data check on the consumption record passes, allocate virtual resources to the consuming user and/or the promoting user from a 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 consuming user and/or the promoting 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 amount of virtual resources allocated to the consuming user and/or the promoting user is inversely proportional to the magnitude of the timestamp.

In this embodiment, the receiving a consumption record corresponding to the target service includes any one or a combination of the following: receiving a consumption record sent by a service agent party 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 resources include: and after the asset issuance guarantee fund provided by the service operator is frozen, the virtual asset is issued in the block chain.

In this embodiment, the node device in the block chain may further receive a second intelligent contract invocation transaction corresponding to the intelligent contract; wherein the second smart contract invocation 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 intelligent contract, invoke second check logic in the intelligent contract, perform data verification on the refund record, and invoke resource transfer logic in the intelligent contract when the data verification on the refund record passes, so as to transfer the virtual resource held by the asset account of the consuming user and/or the promoting user to the preset virtual resource pool.

In this embodiment, the contract account corresponding to the intelligent contract may maintain a state machine corresponding to a virtual resource allocated to the consuming user and/or the promoting user; wherein 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 block chain may further invoke state maintenance logic in the intelligent contract in response to a prompt event that the target service is completed, and 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 block chain may further store the consumption record in a local service database in response to the data check for the consumption record passing; and acquiring the state corresponding to the virtual resource distributed to the consuming user and/or the popularizing user and maintained by the intelligent contract, and setting the 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 block chain may further receive a third intelligent contract invocation transaction corresponding to the intelligent contract; and the third intelligent contract calling transaction comprises revenue data sent by a service provider corresponding to the target service. Subsequently, the node device in the block chain can respond to the third intelligent contract calling transaction, call the third check logic in the intelligent contract, perform data check on the revenue data, and call the calculation logic in the intelligent contract when the data check on the revenue data passes, update the total revenue profit amount of the target service based on the revenue data, further calculate the unit revenue profit amount corresponding to the virtual resource in the virtual resource pool based on the updated revenue profit amount of the preset proportion in the total revenue amount, and the total issuance amount of the virtual resource in the virtual resource pool, and maintain the unit revenue amount in the contract account corresponding to the intelligent contract.

In this embodiment, the node device in the block chain may further receive a resource exchange transaction sent by a user client corresponding to the target service; wherein the resource redemption transaction includes an amount of virtual resources to be redeemed. Subsequently, the node device in the block chain may respond to the resource exchange transaction, invoke resource exchange logic in the intelligent contract, calculate an exchange amount corresponding to the amount of the virtual resource to be exchanged based on the unit revenue profit 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 block chain for deposit, so that when a payment platform monitors the exchange event existing in the block chain, transfer processing is performed from a deposit account corresponding to the service operator to a fund account corresponding to the user client based on the exchange amount.

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

In this case, the node device in the block chain may further invoke asset verification and cancellation logic in the intelligent contract after the transfer processing is completed, and perform verification and cancellation processing on the virtual resource to be exchanged held in the asset account corresponding to the account identifier.

It should be noted that, for a specific manner in which the node device in the block chain executes the steps 1101 to 1103, reference may be made to a specific manner in which the Baas platform executes the steps 1001 to 1003 in the resource issuing method based on the block chain as shown in fig. 10, and this description is not repeated herein.

Corresponding to the foregoing embodiments of the account creation method based on a blockchain, the present specification also provides embodiments of an account creation apparatus based on a blockchain.

The embodiment of the account creation device based on the block chain can be applied to the electronic equipment. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation. From a hardware aspect, as shown in fig. 12, a hardware structure diagram of an electronic device where an account creation apparatus based on a block chain is located in this specification is shown, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 12, the electronic device where the apparatus is located in the embodiment may also include other hardware according to an actual function of the account creation based on the block chain, which is not described again.

Referring to fig. 13, fig. 13 is a block diagram of an account creation apparatus based on a blockchain according to an exemplary embodiment of the present disclosure. The account creation apparatus 130 based on the blockchain may be applied to an electronic device as shown in fig. 12, and the electronic device may serve as a server; wherein, the service operator issues virtual resources on the block chain; the apparatus 130 may include:

the first receiving module 1301 receives an asset account creation request sent by a client; wherein the asset account creation request comprises an account identifier of a user account of the client for the user to log in; the user account is a real-name account of the user;

a first binding module 1302, configured to generate a unique virtual identity for the user in response to the asset account creation request, and bind the account identity and the virtual identity; and the number of the first and second groups,

a creating module 1303, which creates an asset account corresponding to the virtual identity on the blockchain; wherein the first asset account is used to hold the virtual resource issued to a user.

In this embodiment, the apparatus 130 further comprises (not shown in the figure):

the acquisition module is used for acquiring user real-name information associated with the account identifier before the account identifier and the virtual identity identifier are bound;

the query module is used for querying other account identifications related to the user real-name information;

the first binding module 1302:

and binding the account identifier and the other account identifiers with the virtual identity identifier.

the second receiving module is used for receiving the asset account binding request sent by the client; wherein the asset account binding request includes identity information of the user;

and the second binding module responds to the asset account binding request, calls account binding logic in the intelligent contract deployed on the blockchain, binds the identity information and the asset account corresponding to the virtual identity, and stores the binding relationship in the blockchain.

In this embodiment, the asset account binding request further includes a credential that passes identity verification corresponding to the user identity indicated by the identity information; the certificate is issued to the client after the authentication end conducts identity verification corresponding to the user identity indicated by the identity information aiming at the user;

the second binding module:

and calling account binding logic deployed in the intelligent contract on the block chain, carrying out validity check on the certificate passing the identity check, and binding the identity information with the asset account corresponding to the virtual identity when the validity check passes.

In this embodiment, the second binding module:

determining whether an asset account corresponding to the identity information is created on the blockchain;

if the asset account corresponding to the identity information is created on the block chain, the asset account corresponding to the virtual identity is bound with the asset account corresponding to the identity information, and the binding relationship is stored in the block chain;

and if the asset account corresponding to the identity information is not created on the block chain, creating the asset account corresponding to the identity information on the block chain, binding the asset account corresponding to the virtual identity with the asset account corresponding to the identity information, and storing the binding relationship in the block chain.

In this embodiment, the asset account corresponding to the identity information is a temporary account for holding the virtual resource issued to the user.

In this embodiment, the authentication terminal is a third-party authentication mechanism; the certificate passing the identity verification is digitally signed based on a private key of the third-party certification authority;

the second binding module:

verifying the digital signature of the certificate based on a public key which is maintained by the intelligent contract and corresponds to a private key of the third-party certification authority;

and if the digital signature of the certificate is verified, determining that the validity check is passed.

In this embodiment, the server is a Baas platform that manages a plurality of block chains;

the creation module 1303:

and respectively creating asset accounts corresponding to the virtual identity marks on the block chains.

In this embodiment, the virtual resource is value-anchored with a revenue profit amount of a preset proportion in the future revenue profit total amount of the target service.

In this embodiment, the target business comprises a cultural entertainment business.

In this embodiment, the cultural entertainment service includes a movie service; the service operator comprises a delivery party of the movie service; the virtual resource is value anchored to at least a portion of the future box office revenue 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 a portion of the future copyright revenue of the music service.

In this embodiment, the cultural entertainment service includes an online live broadcast service; the service operator comprises an operator of the online live broadcast service; and the virtual resources and at least part of future reward benefits of the online live broadcast service are subjected to value anchoring.

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 a portion of the future advertising revenue for the online video playback service.

In this embodiment, the block chain is a federation chain; and the alliance members of the alliance chain comprise a service operator corresponding to the service end and the service operator.

The implementation process of the functions and actions of each module in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.

The systems, apparatuses, modules or units described in the above embodiments may be specifically implemented by a computer chip or an entity, or implemented by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging 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 forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

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 computer storage media 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, 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 media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

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 an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may 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 may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification 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 and 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, such 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 herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. An account creating method based on a block chain is applied to a server; wherein, the service operator issues virtual resources on the block chain; the method comprises the following steps:

creating an asset account corresponding to the virtual identity on the blockchain; wherein the asset account is used to hold the virtual resource issued to a user.

2. The method of claim 1, prior to binding the account identifier with the virtual identity identifier, the method further comprising:

acquiring user real name information associated with the account identifier;

inquiring other account identifications associated with the user real-name information;

the binding the account identifier and the virtual identity identifier includes:

3. The method of claim 1, further comprising:

receiving an asset account binding request sent by the client; wherein the asset account binding request includes identity information of the user;

and responding to the asset account binding request, calling account binding logic in the intelligent contract deployed on the blockchain, binding the identity information with the asset account corresponding to the virtual identity, and storing the binding relationship in the blockchain.

4. The method of claim 3, the asset account binding request further comprising an identity verified credential corresponding to a user identity indicated by the identity information; the certificate is issued to the client after the authentication end conducts identity verification corresponding to the user identity indicated by the identity information aiming at the user;

the calling an account binding logic in the intelligent contract deployed on the blockchain to bind the identity information with the asset account corresponding to the virtual identity identifier includes:

5. The method according to claim 3 or 4, wherein the binding the identity information with the asset account corresponding to the virtual identity and storing the binding relationship in the blockchain includes:

6. The method of claim 5, the asset account corresponding to the identity information being a temporary account for holding virtual resources issued to the user.

7. The method of claim 4, wherein the certification authority is a third party certification authority; the certificate passing the identity verification is digitally signed based on a private key of the third-party certification authority;

the validity check of the certificate passing the identity check includes:

8. The method of claim 1, the server is a Baas platform that manages a plurality of blockchains;

the creating an asset account corresponding to the virtual identity on the blockchain comprises:

9. The method of claim 1, wherein the virtual resource is value anchored to a pre-determined percentage of the total revenue amount of the target service in the future.

10. The method of claim 9, the virtual resource comprising: and after the asset issuance guarantee fund provided by the service operator is frozen, the virtual asset is issued in the block chain.

11. The method of claim 9, the target business comprising a cultural entertainment business.

12. The method of claim 11, the cultural entertainment service comprising a movie service; the service operator comprises a delivery party of the movie service; the virtual resource is value anchored to at least a portion of the future box office revenue of the movie service.

13. The method of claim 11, 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 a portion of the future copyright revenue of the music service.

14. The method of claim 11, the cultural entertainment service comprising an online live service; the service operator comprises an operator of the online live broadcast service; and the virtual resources and at least part of future reward benefits of the online live broadcast service are subjected to value anchoring.

15. The method of claim 11, the cultural entertainment service comprising an online video playback service; the service operator comprises an operator of the online video playing service; the virtual resource is value anchored with at least a portion of the future advertising revenue for the online video playback service.

16. The method of claim 1, the blockchain is a federation chain; and the alliance members of the alliance chain comprise a service operator corresponding to the service end and the service operator.

17. An account creating device based on a block chain is applied to a server; wherein, the service operator issues virtual resources on the block chain; the device comprises:

the creating module is used for creating an asset account corresponding to the virtual identity on the block chain; wherein the asset account is used to hold the virtual resource issued to a user.

18. The apparatus of claim 17, the apparatus further comprising:

the first binding module:

19. The apparatus of claim 17, the apparatus further comprising:

20. The apparatus of claim 19, the asset account binding request further comprising an identity verified credential corresponding to a user identity indicated by the identity information; the certificate is issued to the client after the authentication end conducts identity verification corresponding to the user identity indicated by the identity information aiming at the user;

the second binding module:

21. The apparatus of claim 19 or 20, the second binding module to:

22. The apparatus of claim 21, the asset account corresponding to the identity information is a temporary account for holding virtual resources issued to the user.

23. The apparatus of claim 20, the certification authority being a third party certification authority; the certificate passing the identity verification is digitally signed based on a private key of the third-party certification authority;

the second binding module:

24. The apparatus of claim 17, the server is a Baas platform that manages a plurality of blockchains;

the creation module:

25. The apparatus of claim 17, wherein the virtual resource is value anchored to a pre-determined percentage of the total revenue amount for the target service in the future.

26. The apparatus of claim 25, the virtual resource comprising: and after the asset issuance guarantee fund provided by the service operator is frozen, the virtual asset is issued in the block chain.

27. The apparatus of claim 25, the target service comprising a cultural entertainment service.

28. The apparatus of claim 27, the cultural entertainment service comprising a movie service; the service operator comprises a delivery party of the movie service; the virtual resource is value anchored to at least a portion of the future box office revenue of the movie service.

29. The apparatus of claim 27, 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 a portion of the future copyright revenue of the music service.

30. The apparatus of claim 27, the cultural entertainment service comprising an online live service; the service operator comprises an operator of the online live broadcast service; and the virtual resources and at least part of future reward benefits of the online live broadcast service are subjected to value anchoring.

31. The apparatus of claim 27, the cultural entertainment service comprising an online video playback service; the service operator comprises an operator of the online video playing service; the virtual resource is value anchored with at least a portion of the future advertising revenue for the online video playback service.

32. The apparatus of claim 17, the blockchain is a federation chain; and the alliance members of the alliance chain comprise a service operator corresponding to the service end and the service operator.

33. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-16 by executing the executable instructions.

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