Disclosure of Invention
The embodiment of the application provides an intelligent contract implementation method and device based on a block chain, which can confirm transaction in the implementation process of an intelligent contract, so as to achieve state consistency.
On one hand, the embodiment of the present application further provides an intelligent contract implementation method based on a block chain, including:
determining the type of the transaction based on the identification of the transaction driving the intelligent contract, wherein the type of the transaction comprises a first type of time length transaction, and the first type of time length transaction is a transaction with execution time length larger than a preset value;
and when the transaction is the first-type duration transaction, performing transaction state management to decouple an intelligent contract operation period and a consensus period.
Optionally, in an embodiment, the performing transaction state management to achieve decoupling of the intelligent contract running period and the consensus period when the transaction is the first type duration transaction includes: when the transaction is the first type of time length transaction, acquiring the state of the transaction every other consensus period; if the transaction state is the ready state, packaging the transaction to obtain a block; and if the transaction state is a non-ready state, inhibiting packaging and block outputting operations of the transaction.
Optionally, in an embodiment, when the state of the transaction is a non-ready state, the non-ready state includes an execution state and a suspension state, and if the state of the transaction is the non-ready state, the inhibiting of the block packing out operation on the transaction includes: if the transaction state is a suspended state, converting the transaction state from the suspended state to an execution state; skipping the transaction when the state of the transaction is the execution state.
Optionally, in an embodiment, if the status of the transaction is a non-ready status, the inhibiting of packaging the transaction out of the block further includes: if the transaction in the execution state is executed in a time slice, converting the state of the transaction from the execution state to the ready state; if the transaction in the execution state is not executed in the time slice, the state of the transaction is converted from the execution state to the suspension state; and if the transaction in the execution state is abnormal or overtime in the execution process, converting the state of the transaction from the execution state to a rollback state.
Optionally, in one embodiment, the amount of fuel consumed increases linearly or exponentially with the length of time the smart contract is operated when the smart contract is driven by the first type of length transaction.
Optionally, in an embodiment, the type of the transaction further includes a second type of time-length transaction, where the second type of time-length transaction is a transaction whose execution time length is not greater than the preset value. The method further comprises the following steps: and when the transaction is the second type of time-length transaction, executing the second type of time-length transaction.
Optionally, in an embodiment, the preset value may be the consensus period, and the preset value may be configurable.
In another aspect, an apparatus for implementing intelligent contracts based on blockchains is provided, including:
the determining module is used for determining the type of the transaction based on the identification of the transaction driving the intelligent contract, wherein the type of the transaction comprises a first type of time length transaction, and the first type of time length transaction is a transaction with execution time length larger than a preset value;
and the management module is used for managing the transaction state when the transaction is the first type of time duration transaction so as to decouple the intelligent contract operation period from the consensus period.
Optionally, in an embodiment, the management module is specifically configured to: when the transaction is the first type of time length transaction, acquiring the state of the transaction every other consensus period; if the transaction state is the ready state, packaging the transaction to obtain a block; and if the transaction state is a non-ready state, inhibiting packaging and block outputting operations of the transaction.
Optionally, in an embodiment, the non-ready state includes an execution state and a suspension state, and the management module is specifically configured to: when the transaction state is a suspended state, converting the transaction state from the suspended state to an execution state; skipping the transaction when the state of the transaction is the execution state.
Optionally, in an embodiment, the management module is further configured to: if the transaction in the execution state is executed in a time slice, converting the state of the transaction from the execution state to the ready state; if the transaction in the execution state is not executed in the time slice, the state of the transaction is converted from the execution state to the suspension state; and if the transaction in the execution state is abnormal or overtime in the execution process, converting the state of the transaction from the execution state to a rollback state.
Optionally, in one embodiment, the amount of fuel consumed increases linearly or exponentially with the length of time the smart contract is operated when the smart contract is driven by the first type of length transaction.
Optionally, in an embodiment, the type of the transaction further includes a second type of time-length transaction, where the second type of time-length transaction is a transaction whose execution time length is not greater than the preset value, and the management module is further configured to: and when the transaction is the second type of time-length transaction, executing the second type of time-length transaction.
Optionally, in an embodiment, the preset value may be the consensus period, and the preset value is configurable.
In another aspect, a computer-readable storage medium having stored thereon computer instructions which, when executed, perform any of the above intelligent contract implementing methods is provided.
The embodiment of the application adopts at least one technical scheme which can achieve the following beneficial effects:
the transactions driving the intelligent contracts are classified according to the identifiers, when the execution duration of the transactions is longer than a preset value, the states of the transactions are managed, so that the decoupling of the running period and the consensus period of the intelligent contracts is realized, the transactions appearing in one consensus period do not need to be executed in the consensus period, but can be executed in a mode of spanning multiple consensus periods, the transaction confirmation failure caused by forced quitting of the transactions in the implementation process of the intelligent contracts can be avoided, and the state consistency is achieved.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Before describing embodiments of the present invention, some terms in this application will be explained.
Block chains: the method is a technology which can maintain a set of non-falsifiable account book records among non-trusted or weakly trusted participants without intermediary participation. A blockchain is a distributed system consisting of many nodes communicating with each other. The blockchain system is generally divided into a public chain, a federation chain and a private chain according to different application scenarios and design systems. Each node of the public chain can freely join and leave the network, participates in reading and writing of data on the chain, and is interconnected and intercommunicated in a flat topological structure during operation, and no centralized service end node exists in the network. The method for realizing the intelligent contract provided by the embodiment of the application can be based on a public chain.
The basic concepts of blockchains may include transactions (transactions), blocks (blocks), and chains (Chain). Wherein: a transaction may refer to an operation that results in a change in the state of the ledger, such as adding a record; the block records the transaction and state results occurring within a period of time, and is a common consensus on the current account book state; the chain is formed by connecting blocks in series according to the occurrence sequence and is a log record of the whole state change. If the blockchain is used as a state machine, each transaction is attempted to change state, and each consensus generated block is that the participant confirms the result of all transaction contents in the block that caused the state change.
And (3) node: a terminal (e.g., a computer) connected to a blockchain network may be considered a node in a blockchain.
Block chain consensus mechanism: may include POS (Proof of rights mechanism), POW (Proof of work), DPOS (delete Proof of rights mechanism) and PBFT (practical Byzantine factory Tolerance). From a probabilistic perspective, the PBFT series of algorithms is deterministic and irreversible once consensus is reached; the POW series algorithm is uncertain, and the probability of being overturned is smaller and smaller as time goes on. The POW guesses a value (nonce) repeatedly by calculation so that the result of adding a new transaction data hash (hash) based on the last block of the block chain satisfies a predetermined condition. Ensure that only a few legal proposals can appear in the system within a period of time. These few legal proposals are broadcast over the network and the receiving user, after authentication, continues to construct new blocks in this way based on the longest chain it considers to be.
Intelligent contract: contracts that are defined in digital form and that are capable of automatically executing terms, i.e., the contents of an intelligent contract, include program code by which automatic execution of contract terms can be achieved.
In the present application, the building and execution of the intelligent contract based on the block chain can be divided into the following steps: (1) multiple users participate in making an intelligent contract together; (2) intelligent contracts are spread and stored in block chains through peer-to-peer (P2P) networks; (3) the intelligent contracts constructed by the block chains are automatically executed.
The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.
Fig. 1 is a flowchart of a method for implementing an intelligent contract based on a blockchain according to an embodiment of the present disclosure. Referring to fig. 1, a method for implementing an intelligent contract based on a block chain according to an embodiment of the present application may include:
and step 12, determining the type of the transaction based on the identification of the transaction driving the intelligent contract, wherein the type of the transaction comprises a first type of time length transaction, and the first type of time length transaction is a transaction with execution time length larger than a preset value.
In other words, the first type of long-duration Transaction can be, for example, a long-duration Transaction (L ong-Range Transaction), and the second type of long-duration Transaction can be, for example, a Short-Range Transaction (Short-Range Transaction). the preset value can be configured according to actual needs in the embodiment of the present application.
In this embodiment, the first type of long-duration transaction may be a transaction requiring occupation of more resources, and the second type of long-duration transaction may be a transaction requiring occupation of less resources. The resources mentioned here may be, for example, CPU resources, memory resources, network resources, and the like.
In the embodiment of the application, each transaction driving the smart contract can be marked with a mark, and the mark can be in any form for playing a role of mark, such as a form of abbreviated letters, for example, a and B, wherein the abbreviated letter a can represent a first type of time duration transaction, and the abbreviated letter B can represent a second type of time duration transaction; such as one or more numbers, e.g., 11 and 22, where the number 11 may represent a first type of long transaction and the number 22 may represent a second type of long transaction; another example is in the form of a short piece of characters, such as abc and qwe, where abc may represent a first type of long transaction and qwe may represent a second type of long transaction. The identification in the embodiment of the present application may also take other forms, for example, a form in which at least two of numbers, letters, and special characters are mixed, and the like.
Of course, in the embodiment of the present application, a default type may also be set for the transaction. The second type of time-length transaction may be set as a default type, since the contract triggered by the transaction initiator for the second type of time-length transaction is expected to be completed with relatively fast execution. The default type of transaction may not set the identifier, and thus, whether the transaction is the first type of long-time transaction or the second type of long-time transaction may be determined by judging whether the transaction carries the identifier. That is, the transaction carrying the identifier is a first type of long-time transaction, and the transaction not carrying the identifier is a second type of long-time transaction. Of course, in the embodiment of the present application, the default type of transaction may also set the identification when needed.
In the embodiment of the application, the identification of the transaction can be preset by a programmer of the intelligent contract, so that the transaction can be determined to be of which type according to the identification carried in the transaction when being executed, and further, the follow-up processing is convenient to carry out.
In the embodiment of the application, the second type of long-time transaction can be executed in a consensus period, and can be accelerated by adopting a stand-alone parallel processing method or a network fragmentation method. For a second type of long-time transaction, if the transaction has not been executed within a specified run-time less than the consensus period, the transaction may be marked as a transaction failure and its state may be rolled back. In the embodiment of the present application, the first type of long transaction may execute a relatively complex application logic, and thus cannot be guaranteed to be completed in a very short time (e.g., a consensus period).
And 14, when the transaction is the first-type duration transaction, performing transaction state management to decouple an intelligent contract operation period and a consensus period.
The transaction status in the embodiments of the present application may include: at least one of a ready state, a suspend state, and an execute state. Decoupling of the smart contract run period and the consensus period may indicate that the smart contract run period is no longer dependent on the consensus period, i.e., the smart contract may execute across multiple consensus periods.
In one embodiment of the present application, the second type of time-long transaction may be executed when the transaction is the second type of time-long transaction. Therefore, the two types of transactions are distinguished and processed differently, so that the transactions of different types can be ensured to be processed properly, failure in transaction confirmation in the implementation process of the intelligent contract is avoided, and state consistency is achieved.
It should be understood that, the execution subjects of the steps of the intelligent contract implementation method based on a blockchain provided in the embodiment of the present application may all be the same device (for example, may be any node in a blockchain network), or the method may also be implemented by different devices. For example, the execution subject of step 12 may be device 1 (e.g., may be one node in a blockchain network), and the execution subject of step 14 may be device 2 (e.g., may be another node in the blockchain network).
Meanwhile, it should be understood that, in the implementation of the intelligent contract implementation method based on the blockchain in the embodiment of the present application, the process of determining the operation elements (e.g., time, random number, and data source) may be consistent with the prior art, and meanwhile, the operation environment may also be substantially consistent with the related art. Taking the determination of time as an example, the whole block chain can be regarded as a timestamp server, and a timestamp of when any block is constructed is obtained, so that the results returned by calling of each distributed node can be completely guaranteed to be consistent.
The method and the device have the advantages that the transactions driving the intelligent contracts are classified according to the identifiers, when the execution duration of the transactions is longer than the preset value, the states of the transactions are managed, the decoupling of the running period and the consensus period of the intelligent contracts is realized, the transactions appearing in the consensus period do not need to be executed in the consensus period, but can be executed in a mode of spanning multiple consensus periods, the transactions can be confirmed in the implementation process of the intelligent contracts, and accordingly state consistency is achieved.
Optionally, in an embodiment of the present application, in step 14, when the transaction is the first type duration transaction, performing transaction state management to decouple the smart contract running period and the consensus period may include: when the transaction is the first type of time length transaction, acquiring the state of the transaction every other consensus period; if the state of the transaction is the ready state, performing packaging block-out operation on the transaction; and if the transaction state is a non-ready state, inhibiting packaging and block outputting operations of the transaction.
As used herein, a "pack out block operation" may refer to packing a transaction into a block for execution by other nodes in the blockchain network to perform computation result validation. Under certain conditions, for example, if the calculation results of more than two thirds of nodes in the whole network are the same, the block nodes can be determined according to the calculation results, and the blocks output by the block nodes are put into the block chain.
When the first-class duration transaction is processed, the transaction state is acquired in each consensus period to determine whether the transaction state is a ready state, only the transaction in the ready state can be packaged to obtain the block, and the transactions in other states cannot be packaged to obtain the block in the current consensus period.
In an embodiment of the present application, the non-ready state includes an execution state and a suspension state, and if the state of the transaction is the non-ready state, the inhibiting of the packaging out of the block operation for the transaction may include: if the transaction state is a suspended state, converting the transaction state from the suspended state to an execution state; and if the state of the transaction is the execution state, skipping the transaction. When the first-type long-time transaction is processed, if the transaction state is determined to be the suspension state, the suspension state is converted into the execution state, and the transaction can be executed conveniently and subsequently.
Optionally, in an embodiment of the present application, for a transaction in an execution state, when the transaction in the execution state is executed within a time slice, the state of the transaction may be converted from the execution state to the ready state; when the transaction in the execution state is not executed within the time slice, the state of the transaction can be converted from the execution state to the suspension state; when the transaction in the execution state is abnormal or overtime in the execution process, the state of the transaction can be converted into a rollback state from the execution state. According to the embodiment of the application, the state switching is carried out on the transaction of the processing execution state based on the specific situation, and the state management of the first-class time length transaction can be better realized.
In addition to classification and lifecycle management by transaction, management of fuel (gas) may also be performed in the embodiments of the present application. Therefore, through the comprehensive management of the three above, the transaction confirmation in the implementation process of the intelligent contract can be better realized, so as to achieve the state consistency. For example, when the smart contract is driven by the first type of duration transaction, the amount of fuel consumed increases linearly or exponentially as the duration of operation of the smart contract increases. Therefore, the intelligent contract driven by the first-type time-length transaction can be managed and controlled on the economic cost, and the condition that a person is ill through the first-type time-length transaction, such as malicious long-term occupation of system computing resources, is ensured.
Fig. 2 is a flowchart of a method for implementing an intelligent contract based on a blockchain according to an embodiment of the present application. Referring to fig. 2, a method for implementing an intelligent contract based on a blockchain according to an embodiment of the present application may include:
and step 22, determining the type of the transaction based on the identification of the transaction driving the intelligent contract, wherein the type of the transaction comprises a first type of time length transaction and a second type of time length transaction.
The first type of time duration transaction is a transaction with the execution time duration being greater than a preset value, and the second type of time duration transaction is a transaction with the execution time duration being not greater than the preset value.
And 24, when the transaction is the first-type duration transaction, acquiring the state of the transaction every other consensus period to determine whether the state of the transaction is a ready state.
And 26, when the state of the transaction is the ready state, packaging the transaction to obtain a block.
And step 28, when the transaction state is a suspension state, converting the transaction state from the suspension state to the execution state.
And step 30, when the transaction state is the execution state, performing state conversion operation based on specific conditions. Step 30 may cover the following situations:
step 301, when the transaction in the execution state is executed in a time slice, converting the state of the transaction from the execution state to the ready state;
step 302, when the transaction in the execution state is not executed in the time slice, the state of the transaction is converted from the execution state to the suspension state;
step 303, when the transaction in the execution state is abnormal or overtime in the execution process, the state of the transaction is converted from the execution state to a rollback state.
And step 32, when the transaction is the second type of time-length transaction, directly executing the second type of time-length transaction.
It should be understood that the relevant contents of the steps shown in fig. 3 can refer to the foregoing description, and are not repeated herein.
The status switching process mentioned herein can also be referred to as shown in fig. 3, and as can be seen from fig. 3, assuming that transaction a is a first type duration transaction, transaction a may be in a suspended state after being accepted. During consensus period T1, transaction A, which is in a suspended state, may be scheduled to execute to transition from the suspended state to an executing state. If transaction A has not been executed within the time slice during the consensus period T1, it returns to the pending state and is ready to be executed again during the next consensus period T2. In the consensus period T2, if the transaction a is executed within the time slice, the execution state is switched to the ready state, and if an exception or timeout occurs during the execution process, the execution state is switched to the rollback state. In the Nth consensus period Tn, where N is greater than 2, if transaction A is ready, then a pack out block operation is performed on transaction A. It should be understood that the schematic diagram of fig. 3 is merely illustrative of one type of state management and is not intended to be limiting.
According to the intelligent contract implementation method based on the block chain, the transactions are classified through the identification, life cycle management of the first-class time duration transactions is achieved through state management, it can be guaranteed that the transactions of different types can be properly processed, failure of transaction confirmation in the implementation process of the intelligent contract is avoided, meanwhile, it can be guaranteed that the first-class time duration transactions can be executed in a mode of spanning multiple consensus cycles, transaction confirmation can be conducted in the implementation process of the intelligent contract, and accordingly state consistency is achieved.
It should also be appreciated that in the embodiments of the subject application, fuel (gas) management may be performed in addition to by classifying transactions and performing lifecycle management. Therefore, through the comprehensive management of the three above, the transaction confirmation in the implementation process of the intelligent contract can be better realized, so as to achieve the state consistency. For example, when the smart contract is driven by the first type of duration transaction, the amount of fuel consumed increases linearly or exponentially as the duration of operation of the smart contract increases. Therefore, the intelligent contract driven by the first-type time-length transaction can be managed and controlled on the economic cost, and the condition that a person is ill through the first-type time-length transaction, such as malicious long-term occupation of system computing resources, is ensured.
Fig. 4 is a block diagram of an apparatus for implementing an intelligent contract based on a blockchain according to an embodiment of the present application. Referring to fig. 4, the intelligent contract implementation apparatus 40 based on a blockchain provided in an embodiment of the present application may include: a determination module 41 and a management module 42. Wherein:
the determining module 41 is configured to determine, based on an identifier of a transaction driving an intelligent contract, a type of the transaction, where the type of the transaction includes a first-class time-length transaction, and the first-class time-length transaction is a transaction whose execution time length is greater than a preset value;
and the management module 42 is configured to perform transaction state management to decouple the intelligent contract running period and the consensus period when the transaction is the first type duration transaction.
Optionally, in an embodiment, the management module 42 is specifically configured to: when the transaction is the first type of time length transaction, acquiring the state of the transaction every other consensus period; if the transaction state is the ready state, packaging the transaction to obtain a block; and if the transaction state is a non-ready state, inhibiting packaging and block outputting operations of the transaction.
Optionally, in an embodiment, the non-ready state includes an execution state and a suspension state, and the management module 42 is specifically configured to: if the transaction state is a suspended state, converting the transaction state from the suspended state to an execution state; and if the state of the transaction is the execution state, skipping the transaction.
Optionally, in an embodiment, the management module 42 is further configured to: if the transaction in the execution state is executed in a time slice, converting the state of the transaction from the execution state to the ready state; if the transaction in the execution state is not executed in the time slice, the state of the transaction is converted from the execution state to the suspension state; and if the transaction in the execution state is abnormal or overtime in the execution process, converting the state of the transaction from the execution state to a rollback state.
Optionally, in one embodiment, the amount of fuel consumed increases linearly or exponentially with the length of time the smart contract is operated when the smart contract is driven by the first type of length transaction.
Optionally, in an embodiment, the type of the transaction further includes a second type of time-length transaction, where the second type of time-length transaction is a transaction whose execution time length is not greater than the preset value, and the management module 42 is further configured to: and when the transaction is the second type of time-length transaction, executing the second type of time-length transaction.
Optionally, in an embodiment, the preset value may be the consensus period, and the preset value is configurable.
The intelligent contract implementation device based on the block chain classifies the transactions driving the intelligent contracts according to the identifiers, and when the execution duration of the transactions is longer than the preset value, the states of the transactions are managed to realize the decoupling of the operation cycle and the consensus cycle of the intelligent contracts, so that the transactions appearing in one consensus cycle do not need to be executed in the consensus cycle, but can be executed by spanning multiple consensus cycles, and the transactions can be confirmed in the implementation process of the intelligent contracts, thereby achieving the state consistency.
In addition, embodiments of the present application may provide a computer-readable storage medium having stored thereon computer instructions, which, when executed, perform any of the above intelligent contract implementation methods.
The computer-readable storage medium provided by the embodiment of the application classifies the transactions driving the intelligent contracts according to the identifiers, and when the execution duration of the transactions is longer than the preset value, the states of the transactions are managed to realize the decoupling of the operation cycle and the consensus cycle of the intelligent contracts, so that the transactions appearing in one consensus cycle do not need to be executed in the consensus cycle, but can be executed across a plurality of consensus cycles, and the transactions can be confirmed in the realization process of the intelligent contracts, thereby achieving the state consistency.
In addition, the embodiments of the present application may also provide a block link node, which may be a computer or a server, for example, and may include a storage medium and a processor. Wherein the storage medium is adapted to store a plurality of instructions; the processor is adapted to execute various instructions stored on the storage medium. Any of the above-described blockchain-based intelligent contract implementation methods may be implemented when instructions stored on the storage medium are executed by a processor.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, apparatus, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention 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 the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
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 application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application 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 the like) having computer-usable program code embodied therein.
The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.