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 described herein.
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.
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.
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.
The block chain or block chain network described in one or more embodiments of the present specification may specifically refer to a P2P network system having a distributed data storage structure, where each node device achieves through a common recognition mechanism, the book data in the block chain is distributed within temporally consecutive "blocks", and the latter block may include a data digest of the former block, and according to a difference of a specific common recognition mechanism (such as POW, POS, DPOS, PBFT, or the like), a full backup of data of all or part of nodes is achieved.
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.
It is contemplated that the embodiments provided herein can be implemented in any suitable type of blockchain network.
The computing device may construct the data into a standard transaction (transaction) format supported by the blockchain, then issue the transaction to the blockchain, perform consensus processing on the received transaction by the node devices in the blockchain, and package the transaction into a block by the node devices serving as accounting nodes in the blockchain after the consensus is achieved, and perform persistent evidence storage in the blockchain.
Regardless of which consensus algorithm is adopted by the block chain, the accounting node can pack the received transaction to generate a latest block and send the latest block to other node devices for consensus verification. If the latest block is received by other node equipment and no problem is proved, 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 transactions contained in the block may also be performed during the process of the other nodes verifying the new block sent by the accounting node.
It should be noted that, each time a block chain generates a latest block, after a transaction in the latest block is executed, the corresponding status of the executed transactions in the block chain changes accordingly, for example, in the block chain structured by an account model, the account status of an external account or an intelligent contract account usually changes correspondingly with the execution of the transaction.
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.
For another example, the "intelligent contract invocation transaction" in the block is used to invoke an intelligent contract deployed on the blockchain, invoke the intelligent contract in the EVM corresponding to the node device to execute the "intelligent contract invocation transaction", and update the account status of the intelligent contract account in the account of the intelligent contract after the execution of the intelligent contract invocation transaction.
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 workshop is used as a programmable block chain, and the core of the ethernet workshop is an ethernet workshop virtual machine (EVM), and each ethernet workshop 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 can execute the Transaction in the EVM, as shown in fig. 1. The From field of the transaction in the figure is used for recording 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 can 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, the intelligent contract causes a virtual account to be generated on the blockchain that contains the contract code and account storage.
As mentioned above, the Data field containing the transaction that created the intelligent contract may hold the byte code 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. The From field of the transaction in the figure is used for recording the address of the account initiating the intelligent contract calling, 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 the parameters for calling the intelligent contract. After invoking the smart contract, the account status of the contract account may change. Subsequently, a client may check the account status of the contract account through the accessed block link points, for example, the account status may be stored in the Storage tree of the intelligent contract in the form of a Key-Value pair. The results of the execution of the transaction that invokes the smart contract, which may be in the form of a transaction receipt (receipt), are stored in the MPT receipt tree.
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.
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 models, Merkle trees are 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 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. For the MPT transaction tree, the MPT receipt tree and the MPT state tree which are organized, the MPT transaction tree, the MPT receipt tree and the MPT state tree are finally stored in a Key-Value type database (such as a levelDB) which adopts a multi-level data storage structure.
In the public chain field, the miners are often encouraged to carry out block chaining out through gas, token and other modes, and the miners can select higher-commission-cost transactions such as gas or token to preferentially pack in blocks so as to increase self income; for the non-miner nodes, although the storage and consensus resources are contributed, corresponding benefits are not obtained. In a token-free (token) -based blockchain model, such as a federation chain, especially in an open federation chain environment, how to count blockchain resources provided by node devices and cover corresponding node costs is also an urgent issue to be solved. At present, there is no method for resource management and charging for users of the blockchain based on the use or occupation of blockchain resources.
In view of the above, one or more embodiments of the present specification provide various resource charging approaches in a blockchain system. It is contemplated that the embodiments provided herein can be implemented in a suitable type of blockchain network, such as a public chain, a federation chain, a private chain, and so forth.
The management platform according to one or more embodiments provided in this specification may include a platform that is provided in or connected to each node device of the blockchain, so as to manage each node device of the blockchain. Optionally, the management platform includes a cloud computing management platform, and correspondingly, the node device of the block chain includes a virtual machine created on a physical host managed by the cloud computing management platform.
The blockchain client described in one or more embodiments provided in this specification may be connected to a node device of a blockchain through the management platform, so as to send a transaction to a blockchain network or obtain a transaction execution result in the blockchain network based on communication with the management platform.
In the blockchain provided in this specification, the management platform performs value anchoring on system resources and virtual resources carried by node devices of the blockchain.
The virtual resources may include digitized forms of real assets circulating under the blockchain, such as assets in the form of currency, real estate, stocks, bonds, loan contracts, notes, accounts receivable, and the like; virtual resources circulating over the blockchain may also be included, such as virtual tokens (e.g., bitcoins, ethercoins, etc.) that begin circulating over the blockchain based on a mine excavation reward that is earned by a billing node (or miner node) of the blockchain packing and successfully adding blocks. Virtual tokens generated based on mineworker node mining typically do not have a value-anchoring relationship with real assets outside the chain; thus, in yet another illustrative embodiment, virtual resources published on a blockchain may include blockchain assets having a value-anchoring relationship with off-chain real assets held by a user, and virtual resources anchored to the frozen real assets and capable of circulation on the chain may be published on the chain by freezing real-world real assets (including assets in the form of currency, real property, stocks, loan contracts, tickets, accounts receivable, and the like).
When the method is realized, the user client side can perform an asset freezing exchange process with the management platform, freeze a certain amount of real assets and send a freezing certificate to the management platform; after receiving the frozen voucher, the management platform can instruct the node device to add virtual resources corresponding to the frozen real asset amount value to the balance of the user's blockchain account on the blockchain based on the frozen voucher.
The virtual resource corresponding to the frozen real asset amount value is added into the balance of the user's blockchain account based on the frozen certificate, and the method can be further realized by the interaction between the user and an intelligent contract: the management platform triggers a virtual resource exchange transaction sent to a blockchain network, wherein the virtual resource exchange transaction comprises the asset freezing voucher; responding to the virtual resource exchange transaction, the node equipment of the blockchain calls a virtual resource exchange contract deployed on the blockchain, executes the resource exchange logic declared by the intelligent contract, and adds virtual resources corresponding to the real asset amount value frozen by the asset freezing voucher into the account balance of the blockchain of the user.
Based on the mode, the user can obtain virtual resources which can be anchored with the value of the real assets in the block chain network based on the real assets held by the user, and the virtual resources can be expressed as the balance of the account on the chain of the user.
In the blockchain network system, the system resources provided by the blockchain node devices for the blockchain service can be value-anchored with the virtual resources. For example, the storage resources provided by the node device for the data on the blockchain may perform value anchoring with the virtual resources, and the blockchain data per storage unit capacity may obtain the virtual resources corresponding thereto; for another example, the CPU computational resources provided by the node device for executing any transaction on the blockchain may perform value anchoring with the virtual resources, and each CPU instruction set of the execution unit number may obtain the virtual resources corresponding thereto; for another example, the node device may perform value anchoring with the virtual resource for a network resource provided by broadcast or consensus of any transaction on the block chain, and may obtain the corresponding virtual resource based on network traffic consumed in the broadcast or consensus process of the uplink transaction.
The block chain developer or the management platform may quantify the system resources in the form of the storage resources, the computing resources, the network resources, and the like, and price the number of virtual resources corresponding to each unit of the storage resources, the computing resources, the network resources, or the system resources in other forms in the block chain network. For a federation chain, whose federation members are relatively fixed, the system resource pricing resulting from the anchoring can remain fixed for a longer period of time; for a public link system, nodes enter or exit a blockchain network more frequently, and after a blockchain developer performs unit pricing on the system resources in various forms, the blockchain developer performs real-time virtual resource transfer based on the blockchain scale when a user uses the blockchain, or performs periodic virtual resource transfer according to a shorter period. Those skilled in the art can also deduct virtual resources from the actual cost requirement to the user for the blockchain service provided by the blockchain node device based on any form of system resources having a value anchor relationship with the virtual resources, which is not limited in the present specification.
After the intelligent contract is created and deployed in the blockchain, the management platform may maintain attribute contents of the storage space allocated by the node device of the blockchain for the intelligent contract account, which may specifically include a storage space capacity allocated by the node device for the intelligent contract account, a remaining storage space capacity, and/or an effective duration (or an effective period) of the storage space capacity allocated by the node device for the intelligent contract account.
For example, a user may apply for a specified storage space capacity for an intelligent contract account when creating an intelligent contract, and the management platform maintains and records the specified storage space capacity, or maintains and records a remaining available storage space capacity after the intelligent contract is deployed or invoked; in the process of invoking and executing the intelligent contract, if the initially specified storage space capacity of the user cannot enable the intelligent contract to invoke the successful execution of the transaction (when the storage space occupation required by the intelligent contract account after the intelligent contract invoking transaction is completed is larger than the specified storage space capacity), the user can apply for expanding the storage space capacity of the intelligent contract account from the management platform. Alternatively, when the user considers that the initially designated storage space is too large, the user may apply to the blockchain system to reduce the storage space capacity of the intelligent contract account.
For another example, the user may apply for the effective duration of the specified storage space for the intelligent contract account when creating the intelligent contract, when the effective duration expires, the blockchain system may stop providing services for the intelligent contract (e.g., real-time intelligent contract invoking services), and the user may apply for the effective duration of the storage space for expanding the intelligent contract account to the management platform in order to extend the duration for which the blockchain system provides services for the intelligent contract. Or, if the user considers that the effective duration of the initially specified storage space is too long, the user may apply to the management platform to reduce the effective duration of the storage space of the intelligent contract account.
It is noted that the storage space capacity allocated by the node device to the target intelligent contract account maintained in the management platform may not be the storage space capacity actually allocated by the node device to the target intelligent contract account at the current time, but may be the maximum storage space capacity allocated by the node device to the target intelligent contract account.
The capacity of the storage space carried by the node device of the blockchain and/or the effective duration of the storage space carried by the node device of the blockchain can be value-anchored with the virtual resource released on the blockchain. For example, the blockchain system may price the storage resources provided by the node devices for the intelligent contract account: m (virtual resource units)/Gb, or, m (virtual resource units)/Gb/day.
It is noted that the pricing of the storage resources provided by the node devices by the blockchain system may be related to the number of nodes of the blockchain system, and it is expected that the more node devices of the blockchain, the more total amount of the storage resources actually occupied by the intelligent contract account, and therefore, the blockchain system may adjust the pricing per unit of the storage resources charged to the user based on the number of node devices.
The management user of the intelligent contract can manage the storage space of the intelligent contract account by sending a storage space management request to the management platform, so that the storage space of the intelligent contract account is expanded or reduced, the effective duration of the storage space of the intelligent contract account is prolonged or shortened, and corresponding virtual resource transfer or receiving is carried out based on the quantity of the virtual resources anchored with the storage resources.
As shown in fig. 4, an exemplary embodiment of the present specification provides a method for managing storage space of an intelligent contract account, including:
step 402, the management platform receives a storage space management request sent by a blockchain client, where the storage space management request includes a capacity for expanding a storage space capacity allocated to a target intelligent contract account by a node device, and/or an effective duration for expanding an effective duration of a storage space allocated to the target intelligent contract account by the node device.
Optionally, the storage space management request may further include identification information of the target intelligent contract account, so that the management platform may retrieve, based on the identification information of the target intelligent contract account, states of the node device maintained in the platform, such as storage space capacity and effective duration allocated to the target intelligent contract account.
Step 404, calculating a first amount of the virtual resource anchored to the expanded capacity and/or to the expanded effective duration value, such that the user's virtual resource account is deducted by the first amount of the virtual resource.
For example, the management platform may price storage resources provided by the node devices: m (virtual resource units)/Gb, where a user requests NGb extended capacity for an account of the target smart contract in a storage space management request, the management platform may calculate a first amount of the virtual resources to which the extended capacity value is anchored, and may include: m N (virtual resource units).
As another example, the management platform may price storage resources provided by the node device: m (virtual resource unit)/Gb/day, the capacity of the storage space allocated by the node equipment for the target intelligent contract account is NGB; the method includes that a user expands an effective duration of h days for an account request of the target intelligent contract in a storage space management request, and the management platform can calculate a first quantity of the virtual resources with the value of the expanded effective duration anchored, and may include: m N h (virtual resource unit).
For another example, the management platform may price storage resources provided by the node device: m (virtual resource unit)/Gb/day, the capacity of the storage space allocated by the node equipment for the target intelligent contract account is NGB; the method includes that a user requests to expand an effective duration of h days and an expanded capacity of a PGB (product group bus) for an account of the target intelligent contract in a storage space management transaction, and the management platform can calculate a first quantity of the virtual resources anchored with the expanded capacity and the expanded effective duration value, and comprises the following steps: m (N + P) h (virtual resource unit).
The virtual resource account of the user is an account storing the same type of resources as the virtual resources; when the virtual resource is an out-of-chain real resource, the virtual resource account may include a currency account (such as a bank account), or a virtual point account which is established on the management platform by the user and uses currency conversion; when the virtual resource is a virtual resource issued on a blockchain, the virtual resource account may include a user's blockchain account.
When the virtual resource account of the user is a money account, the entity that deducts the first amount of virtual resources from the virtual resource account of the user may be a financial institution such as a bank, and may transfer the deducted first amount of virtual resources to a money account corresponding to a management platform; when the virtual resource account of the user is a virtual coin or a virtual point account established on the management platform, the entity for deducting the first amount of virtual resources from the virtual resource account of the user may be the management platform; when the virtual resource account of the user is a blockchain account, the entity that performs deduction of the first amount of virtual resources from the virtual resource account of the user may be a node device of a blockchain, and may transfer the deducted first amount of virtual resources to a blockchain account corresponding to a management platform.
The present embodiment does not limit the execution body, the deduction opportunity, and the specific manner of deducting the first amount of virtual resources from the virtual resource account of the user.
The management platform may send a payment instruction of the first amount of virtual resources to the user client after calculating the first amount of virtual resources anchored to the extended capacity and/or to the extended validity duration value.
For example, the user client may push a cash payment page on a user interface of the client, so that the financial institution corresponding to the cash account of the user performs the deduction of the first amount of virtual resources from the cash account of the user in response to payment verification information (e.g., a digital password, biometric identification information) input by the user at the client.
For another example, the user client may push, on a user interface of the client, a virtual point payment page circulated on the management platform, where the virtual point is obtained by exchanging money and cash on the management platform by the user and is stored in a virtual point account opened on the management platform by the user, so that, in response to payment verification information (e.g., a digital password, biometric identification information) input by the user at the client, the management platform deducts the first amount of virtual resources from the virtual point account of the user on the management platform.
When the virtual resource is a virtual resource issued on a blockchain, the management platform may construct a page for the transfer transaction on the blockchain, which is pushed on a user interface of the client, so that the blockchain client may further send the transfer transaction to the blockchain through the management platform, so that after the transfer transaction is verified by the blockchain, the node device of the blockchain deducts the virtual resource of the first quantity from the blockchain account of the user, or deducts the virtual resource of the first quantity from the blockchain account of the user and transfers the virtual resource of the first quantity to the blockchain account corresponding to the management platform. Thereafter, the management platform may thereafter learn from the node device whether the transfer transaction was successfully performed.
If the deduction process fails due to the fact that the number of the virtual resources held by the virtual resource account of the user is smaller than the first number, or the management platform does not acquire a message that the virtual resource account of the user of the client is deducted from the first number of the virtual resources within a preset time limit, the management platform may return a prompt that the execution of the storage space management request fails to the blockchain client.
In one or more embodiments, after the management platform learns that the virtual resource account of the user is successfully deducted from the first amount of virtual resources, the management platform may hold the virtual resource account of the first amount of virtual resources, which is allocated to the user or mechanism entity corresponding to the node device of the block chain based on a preset period (including real-time or periodically), so as to complete the allocation of the virtual resources to the user or mechanism entity providing the system resources in the block chain system.
The present embodiment does not limit the specific manner in which the virtual resources are allocated. For example, the management platform may allocate the received currency cash or the currency cash corresponding to the deducted virtual credits to a currency cash account of a user or institution entity corresponding to the node device of the blockchain, or the management platform may allocate virtual resources issued on the chain received in the blockchain account to a blockchain account of a user or institution entity corresponding to the node device of the blockchain, and then, in response to a redemption request of the user or institution, redeem the virtual resources allocated in the blockchain account thereof to entity assets outside the chain, and perform logout processing on the redeemed virtual resources on the chain.
The rule for allocating the first amount of virtual resources to the blockchain account corresponding to each node device in the blockchain is not specifically limited in this specification. For example, the node device may averagely allocate the deducted virtual resources of the first quantity to virtual resource accounts of users or institution entities corresponding to the node devices of the block chain to hold the virtual resources.
Or, based on the storage medium performance attribute of the account storage resource allocated to the intelligent contract by each node device of the block chain, the virtual resource accounts allocated to the users or the mechanism entities corresponding to each node device of the block chain from the first number of virtual resources are respectively held. For example, since the storage medium configurations of the node devices are different, the blockchain system may rank the storage medium of each node device based on the storage medium performance attribute (e.g., hard disk performance attribute such as hdd, ssd, or nvm) of each node device obtained by monitoring each node device, so as to allocate a higher proportion of virtual resources to the node device providing a high-level storage medium and allocate a lower proportion of virtual resources to the node device providing a low-level storage medium.
And 406, changing the remaining storage capacity of the storage space allocated to the target intelligent contract account by the node device maintained by the management platform based on the extended capacity and/or the extended effective duration, and/or changing the remaining effective duration.
The changing process may specifically include, based on the extended capacity, increasing a remaining storage capacity of a storage space allocated to the target intelligent contract account by the node device maintained by the management platform; and/or based on the extended effective duration, increasing the residual effective duration of the storage space allocated to the target intelligent contract account by the node equipment maintained by the management platform.
In the service life of the intelligent contract, the user may correspondingly expand or reduce the capacity of the storage space allocated by the node device to the target intelligent contract account according to the actual demand, and/or correspondingly expand or reduce the effective duration of the storage space allocated by the node device to the target intelligent contract account, so as to change the state of the remaining storage capacity and/or the state of the remaining effective duration of the storage space allocated by the node device maintained in the management platform to the target intelligent contract account.
For example, in another illustrated embodiment, the method for managing storage space of an intelligent contract account further includes: receiving a storage space management request sent by a block chain client, wherein the storage space management request comprises capacity for reducing the capacity of a storage space allocated to a target intelligent contract account by a node device and/or effective duration for reducing the effective duration of the storage space allocated to the target intelligent contract account by the node device;
calculating a second amount of the virtual resource anchored to the reduced capacity, and/or to the reduced length of validity value, such that the user's virtual resource account is increased by the second amount of virtual resource;
and changing the residual storage capacity and/or the residual effective duration of the storage space, which is maintained by the block chain and allocated by the node equipment for the target intelligent contract account, based on the reduced capacity and/or the reduced effective duration.
In yet another illustrated embodiment, the management platform may further forward a storage space management request of a user for the target intelligent contract account to a node device in the blockchain in the form of a blockchain transaction or in the form of a high-authority system administrator instruction, so that the node device maintained in the blockchain performs modification processing on the remaining storage capacity and/or the remaining effective duration of the storage space allocated for the target intelligent contract account.
In specific implementation, the node device may extend a content field (except Balance, Nonce, Code, and Storage) supported by the target intelligent contract account, so as to increase Storage resource variable parameters (such as total capacity of the account Storage space, remaining capacity of the account Storage space, and effective duration of the account Storage space) provided for the target intelligent contract by the node device that identifies the block chain.
Corresponding to the above flow implementation, the embodiment of the present specification further provides a storage space management device 50 for an intelligent contract account. The apparatus 50 may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, the logical device is formed by reading a corresponding computer program instruction into a memory for running through a Central Processing Unit (CPU) of the device. In terms of hardware, the device in which the apparatus is located generally includes other hardware such as a chip for transmitting and receiving wireless signals and/or other hardware such as a board for implementing a network communication function, in addition to the CPU, the memory, and the storage shown in fig. 6.
As shown in fig. 5, the present specification provides a storage space management apparatus 50 for an intelligent contract account, which is applied to a management platform for performing management on node devices of a blockchain, where the management platform maintains a remaining storage capacity and/or a remaining effective duration of a storage space allocated by the node device for a target intelligent contract account; the capacity of a storage space carried by the node equipment of the block chain and/or the effective duration of the storage space carried by the node equipment of the block chain are/is subjected to value anchoring with the virtual resources;
the apparatus 50 comprises:
a receiving unit 502, configured to receive a storage space management request sent by a blockchain client, where the storage space management request includes a capacity for expanding a capacity of a storage space allocated by a node device for a target intelligent contract account, and/or an effective duration for expanding an effective duration of the storage space allocated by the node device for the target intelligent contract account;
a calculating unit 504 for calculating a first amount of the virtual resource anchored to the expanded capacity and/or to the expanded value of the validity duration;
a changing unit 506, configured to, after the first amount of virtual resources are deducted from the virtual resource account of the user, change, based on the extended capacity and/or the extended effective duration, the remaining storage capacity of the storage space allocated by the node device maintained by the management platform for the target intelligent contract account and/or the remaining effective duration.
In yet another illustrated embodiment, the apparatus 50 further comprises:
an allocating unit 508, configured to allocate the first number of virtual resources to a virtual resource account corresponding to a node device of the block chain for holding.
In yet another illustrated embodiment, the allocating unit 508 further includes:
averagely distributing the first quantity of virtual resources to virtual resource accounts corresponding to the node devices of the block chain for holding;
or, based on the storage medium performance attribute of the account storage resource allocated to the intelligent contract by each node device of the block chain, allocating the first number of virtual resources to the virtual resource account corresponding to the node device of the block chain for holding.
In yet another illustrated embodiment, the receiving unit 502 is further configured to receive a storage space management request sent by a blockchain client, where the storage space management request includes a capacity for reducing a storage space capacity allocated by a node device for a target intelligent contract account and/or a duration for reducing a duration of validity of a storage space allocated by the node device for the target intelligent contract account;
the calculating unit 504 is further configured to calculate a second amount of the virtual resource anchored with the reduced capacity and/or the reduced duration of validity value, such that the user's virtual resource account is increased by the second amount of the virtual resource;
the changing unit 506 is further configured to change, based on the reduced capacity and/or the reduced validity duration, a remaining storage capacity of a storage space that is maintained by the block chain and allocated by the node device for the target intelligent contract account, and/or a remaining validity duration.
In yet another illustrated embodiment, the apparatus 50 further comprises:
returning unit 510, if the virtual resource account of the user is not successfully deducted the first amount of virtual resources within a preset time limit, returning a prompt that the execution of the storage capacity management transaction fails to the blockchain client.
In yet another illustrated embodiment, the virtual resource is a blockchain asset published on a blockchain anchored as value to an off-chain asset held by a user.
The specific implementation processes of the functions and actions of each unit in the device 50 are detailed in the implementation processes of corresponding steps in the storage space management method for an intelligent contract account executed by the management platform, and relevant parts may be referred to part of the description of the method embodiment, which is not described herein again.
The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units 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 units or 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 apparatuses, units and modules illustrated in the above embodiments may be implemented by a computer chip or an entity, or 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.
Corresponding to the above method embodiments, embodiments of the present specification further provide a computer device, as shown in fig. 6, including a memory and a processor. Wherein the memory has stored thereon a computer program executable by the processor; when the processor runs the stored computer program, the processor executes each step of the method for managing the storage space of the intelligent contract account executed by the schoolbag management platform. For a detailed description of each step of the method for managing storage space of an intelligent contract account performed by the management platform, please refer to the previous contents, and it is not repeated.
The above description is only a preferred embodiment of the present disclosure, and should not be taken as limiting the present disclosure, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the present disclosure should be included in the scope of the present disclosure.
In a typical configuration, a computing device 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 tape magnetic disk storage 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.
As will be appreciated by one skilled in the art, embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.