METHOD AND DEVICE FOR PREVENTING FORKING OF BLOCKCHAIN

Abstract

Disclosed is a method and device for preventing blockchain forking. The method includes: selecting s consecutive blocks B.sub.n to B.sub.n+s; generating a key pair for block B.sub.m by a node A.sub.n that creates the block B.sub.n; holding the node A.sub.n active in the blockchain's continuously generating blocks B.sub.n+1 to B.sub.n+s until the block B.sub.n+s of s consecutive blocks becomes tamper-proof; in response to that, signing on the block Ba.sub.n+s with the private key PK′.sub.n; in response to the blockchain's subsequently generating a block B.sub.m(m>n+s), placing the signature in B.sub.m; making nodes creating each of the s blocks B.sub.n to B.sub.n+s all execute afore-mentioned steps, thereby forming multiple backlinks associated with the blockchain's block size. The number of backlinks is used for determining blockchain forking by a newly-added node creating a new block.

Claims

1. A method for preventing forking of a blockchain, characterized in that the method is realized by establishing a backlink for each block of the blockchain and making a determination according to a number of backlinks, comprising steps of: S101, selecting s consecutive blocks B.sub.n to B.sub.n+s; S102, generating, by a node A.sub.n that creates the block B.sub.n in the s consecutive blocks, a key pair for the block B.sub.n, wherein the block B.sub.m contains a public key PK.sub.n in the key pair, and a private key PK′.sub.n in the key pair is held individually by the node A.sub.n; S103, holding the node A.sub.n active in a process of continuous generation of blocks B.sub.n+1 to B.sub.n+s in the blockchain until the block B.sub.n+s in the s consecutive blocks becomes a tamper-proof block; S104, in response to the block B.sub.n+s in the s consecutive blocks becoming a tamper-proof block, using the private key PK′.sub.n to sign on the block B.sub.n+s; S105, in response the to subsequent generation of a block B.sub.m in the blockchain, placing the signature in the block B.sub.m, where m>n+s; S106, making nodes creating each of the s consecutive blocks B.sub.n to B.sub.n+s all execute steps S102 to S105, thereby forming a plurality of backlinks associated with a block size of the blockchain, wherein each block is proven by a preceding block to be present on a main chain of the blockchain; and S107, when a new chain claiming to be on the legitimate main chain of the blockchain is received, determining by a newly added node whether the new chain forks according to the number of the backlinks, which comprises: in case that there are L backlinks in any s consecutive blocks of the new chain, in response to the condition that G>s/2 and Ls/2, determining the new chain to be a main chain that does not fork; in response to the condition that 1Gs/2 and L>s-G, determining the new chain to be a main chain that does not fork; in response to the condition that L<G, determining the new chain to be a forked chain; and in response to the condition that GLs-G, determining that it cannot be decided whether the new chain forks, wherein G represents a minimum number of trustworthy nodes in the s consecutive blocks.

2. The method of claim 1, characterized in that the node A.sub.n uses only once the private key PK′.sub.n, and a key pair for each of the s consecutive blocks B.sub.n to B.sub.n+s is regenerated.

3. The method of claim 1, characterized in that the public key PK.sub.n is generated based on a hash signature algorithm, wherein the hash signature algorithm comprises a Lamport algorithm.

4. The method of claim 1, characterized in further comprising placing the signature in a location other than the block B.sub.n+s of the blockchain to ensure that the signature can be placed in the block B.sub.m in the S105.

5. The method of claim 4, characterized in that the signature is deposited as a transaction in the blockchain.

6. The method of claim 4, characterized in that the signature is copied to obtain a copied signature and both the signature and the copied signature are stored on the blockchain.

7. The method of claim 1, characterized in that legitimacy of the signature is checked before execution of the S105, and the signature passing the legitimacy check proceeds to be executed with the S105, while the signature not passing the legitimacy check is considered by the blockchain as an illegitimate signature, and thereby is refused to be executed with the S105.

8. The method of claim 1, characterized in that the signature process is performed in a trusted execution environment.

9. The method of claim 1, characterized in that the blockchain is a public chain.

10. The method of claim 1, characterized in that a Genesis block of the blockchain is fully trusted, wherein a node of the Genesis block or a node of another block authorized by the Genesis block establishes a first backlink for the Genesis block, and after the first backlink appears, a probability of forking occurring within the s consecutive blocks covered by the first backlink is zero.

11. The method of claim 1, characterized in that determination of whether a new block is a head on the forked chain cannot be achieved in a case where a small amount of blocks exist at a head and tail of the blockchain, the method comprising: in a case where the new block is at a position of a closest suspected forking point, all blocks before the new block are in the main chain, and a node creating the new block has not formed and placed a complete backlink in the blockchain, performing a short-term signature on a block or a block sequence that has been tamper-proof in successor blocks of the new block, and placing the short-term signature in one or more storage positions, so that when the number of successor blocks that have backlinks of the new block is less than s, if the short-term signature is not in real-time or expired, the short-term signature is used instead of the backlinks for determination; determining that the new block is on the forked chain in response to the short-term signature being absent or expired; or continuously waiting until a predetermined number of the backlinks are formed from the block to be determined by executing S101-S106 of the method, and determining whether the block to be determined is a head on the forked chain by determining whether the number of the backlinks satisfies the numerical range of S107.

12. The method of claim 1, characterized in further comprising performing a search on a chain portion other than the main chain of the blockchain to confirm whether there exists a duplicate signer that performs duplicate signature on the backlinks, wherein the duplicate signer represents a plurality of nodes that perform signature on two blocks to be generated, and the two blocks to be generated are respectively on the main chain and the forked chain, so that the forked chain is found according to a block created by the duplicate signer.

13. The method of claim 1, characterized in that for a suspected forked chain, a main chain portion before the suspected forked chain and a chain structure after an intersection of the suspected forked chain and the main chain are compared, wherein the main chain comprises the backlinks, and if a comparison result shows a significant difference in the number of the backlinks, the suspected forked chain is determined to be a forked chain, or otherwise the suspected forked chain is determined to be a main chain.

14. The method of claim 1, characterized in that in response to using the private key PK′.sub.n to sign on the block B.sub.n+s in the S104, the private key PK′.sub.n is deleted to prevent it from being abused.

15. A device for preventing forking of blockchain, characterized in comprising a blockchain and a processor, wherein the blockchain can ensure that information published thereon is tamper-proof, and the processor is configured to: selecting s consecutive blocks B.sub.n to B.sub.n+s; generating, by a node A.sub.n that creates the block B.sub.m in the s consecutive blocks, a key pair for the block B.sub.m, wherein the block B.sub.m contains a public key PK.sub.n in the key pair, and a private key PK′.sub.n in the key pair is held individually by the node A.sub.n; holding the node A.sub.n active in a process of continuous generation of blocks B.sub.n+1 to B.sub.n+1n the blockchain until the block B.sub.n+s in the s consecutive blocks becomes a tamper-proof block; in response to the block B.sub.n+s in the s consecutive blocks becoming a tamper-proof block, using the private key PK′.sub.n to sign on the block B.sub.n+s; in response to the subsequent generation of a block B.sub.m in the blockchain, placing the signature in the block B.sub.m, where m>n+s; making nodes creating each of the s consecutive blocks B.sub.n to B.sub.n+s all execute the foregoing processes, thereby forming a plurality of backlinks associated with a block size of the blockchain, wherein each block is proven by a preceding block to be present on a main chain of the blockchain; and when a new chain claiming to be on the legitimate main chain of the blockchain is received, determining by a newly added node whether the new chain forks according to the number of the backlinks, which comprises: in case that there are L backlinks in any s consecutive blocks of the new chain, in response to the condition that G>s/2 and Ls/2, determining the new chain to be a main chain that does not fork; in response to the condition that 1 Gs/2 and L>s-G, determining the new chain to be a main chain that does not fork; in response to the condition that L<G, determining the new chain to be a forked chain; and in response to the condition that GLs-G, determining that it cannot be decided whether the new chain forks, wherein G represents a minimum number of trustworthy nodes in the s consecutive blocks.

16. The device of claim 15, characterized in that the node A.sub.n uses only once the private key PK′.sub.n, and a key pair for each of the s consecutive blocks B.sub.n to B.sub.n+s is regenerated.

17. The device of claim 15, characterized in that the public key PK.sub.n is generated based on a hash signature algorithm, wherein the hash signature algorithm comprises a Lamport algorithm.

18. The device of claim 15, characterized in that the processor is further configured to place the signature in a location other than the block B.sub.n+s of the blockchain to ensure that in response to the subsequent generation of a block B.sub.m in the blockchain, the signature can be placed in the block B.sub.m.

19. The device of claim 18, characterized in that the processor is configured to deposit the signature as a transaction in the blockchain.

20. The device of claim 18, characterized in that the processor is configured to copy the signature to obtain a copied signature and store both the signature and the copied signature on the blockchain.

21. The device of claim 15, characterized in that the processor is further configured to, in response to the subsequent generation of a block B.sub.m in the blockchain, check legitimacy of the signature before placing the signature in the block B.sub.m, wherein the signature passing the legitimacy check proceeds to be executed with placing the signature in the block B.sub.m, while the signature not passing the legitimacy check is considered by the blockchain as an illegitimate signature, and thereby is refused to be executed with placing the signature in the block B.sub.m.

22. The device of claim 15, characterized in that the signature process is performed in a trustworthy execution environment.

23. The device of claim 15, characterized in that the blockchain is a public chain.

24. The device of claim 15, characterized in that a Genesis block of the blockchain is fully trusted, wherein a node of the Genesis block or a node of another block authorized by the Genesis block establishes a first backlink for the Genesis block, and after the first backlink appears, a probability of forking occurring within the s consecutive blocks covered by the first backlink is zero.

25. The device of claim 15, characterized in that determination of whether a new block is a head on the forked chain cannot be achieved in a case where a small amount of blocks exist at the head and tail of the blockchain, the processor is configured to: in a case where the new block is at a position of a closest suspected forking point, all blocks before the new block are in the main chain, and a node creating the new block has not formed and placed a complete backlink in the blockchain, performing a short-term signature on a block or a block sequence that has been tamper-proof in successor blocks of the new block, and placing the short-term signature in one or more storage positions, so that when the number of successor blocks that have backlinks of the new block is less than s, if the short-term signature is not in real-time or expired, the short-term signature is used instead of the backlinks for determination; determining that the new block is on the forked chain in response to the short-term signature being absent or expired; or continuously waiting until a predetermined number of the backlinks are formed from the block to be determined, and determining whether the block to be determined is a head on the forked chain by determining whether the number of the backlinks satisfies a predetermined numerical range.

26. The device of claim 15, characterized in that the processor is further configured to perform a search on a chain portion other than the main chain of the blockchain to confirm whether there exists a duplicate signer that performs the duplicate signature on the backlinks, wherein the duplicate signer represents a plurality of nodes that perform signature on two blocks to be generated, and the two blocks to be generated are respectively on the main chain and the forked chain, so that the forked chain is found according to a block created by the duplicate signer.

27. The device of claim 15, characterized in that the processor is configured to, for a suspected forked chain, compare a main chain portion before the suspected forked chain and a chain structure after an intersection of the suspected forked chain and the main chain, wherein the main chain comprises the backlinks, and if a comparison result shows a significant difference in the number of the backlinks, the suspected forked chain is determined to be a forked chain, or otherwise the suspected forked chain is determined to be a main chain.

28. The device of claim 15, wherein the processor is configured to, in response to using the private key PK′.sub.n to sign on the block B.sub.n+s, delete the private key PK′.sub.n to prevent it from being abused.

29. A machine-readable storage medium stored a computer program thereon, wherein the computer program, when executed by a processor, implements the method for preventing forking of blockchain of any one of claims 1 to 14.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The novel features of the present invention are set forth in detail in the appended claims. A better understanding of the features and advantages of the present invention will be obtained by reference to the following detailed description and accompanying drawings in which illustrative embodiments utilizing the principles of the present invention are set forth. The drawings are only for the purpose of illustrating the embodiments and should not be considered as limiting the invention. And throughout the drawings, the same elements are denoted by the same reference numerals, in which:

[0048] FIG. 1 illustrates a flowchart of a method for preventing forking of blockchain according to an exemplary embodiment of the present disclosure:

[0049] FIG. 2 illustrates a schematic diagram of a single backlink according to an exemplary embodiment of the present disclosure;

[0050] FIG. 3 illustrates a schematic diagram of a possible behavior pattern of a malicious node under a backlink mechanism according to an exemplary embodiment of the present disclosure;

[0051] FIG. 4 illustrates a state diagram when determination of whether a new block is a head on a forked chain cannot be achieved according to a conventional method in a case where a small number of blocks exist in the head and tail of the blockchain according to an exemplary embodiment of the present disclosure:

[0052] FIG. 5 illustrates a schematic diagram of three link forms associated with backlinks always present throughout the blockchain according to an exemplary embodiment of the present disclosure:

[0053] FIG. 6 illustrates a state diagram when determination of whether a new block is a head on a forked chain cannot be achieved according to a conventional method in a case where a block B.sub.m does not exist according to an exemplary embodiment of the present disclosure:

[0054] FIG. 7 illustrates a state diagram when determination of whether a new block is a head on a forked chain cannot be achieved according to a conventional method in a case where a block B.sub.m, has not become a tamper-proof block according to an exemplary embodiment of the present disclosure;

[0055] FIG. 8 illustrates a state diagram when determination of whether a new block is a head on a forked chain cannot be achieved according to a conventional method in a case where a block B.sub.m has not been formed according to an exemplary embodiment of the present disclosure;

[0056] FIG. 9 illustrates a schematic diagram of a backlink pattern formed in a case where a complete backlink, a calculated but unplaced link (i.e., where the block B.sub.m has not occurred), and an unused link (i.e., where the block B.sub.m has not occurred) exist simultaneously on a main chain of the blockchain after formation of the backlink mechanism, according to an exemplary embodiment of the present disclosure; and

[0057] FIG. 10 illustrates a schematic structural diagram of a device for preventing blockchain forks according to an exemplary embodiment of the present disclosure.

DETAILED DESCRIPTION OF THE INVENTION

[0058] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure will be more thoroughly understood, and will fully convey the scope of the present disclosure to those skilled in the art. Nothing in the following detailed description is intended to indicate that any particular component, feature, or step is essential to the present invention. Those skilled in the art will appreciate that various features or steps may be substituted for or combined with each other without departing from the scope of the present disclosure.

[0059] A blockchain applied in this embodiment is composed of a series of blocks at any time, that is, the format of a public chain is composed of a series of numerical blocks. Those skilled in the art can understand that the number of blocks can be defined using the number of blocks in any manner known in the art or in the future, such as several millions or more, and the present invention is not limited in this respect.

[0060] FIG. 1 illustrates a flowchart of a method for preventing blockchain forks according to an exemplary embodiment of the present disclosure. As shown in FIG. 1, a backlink method for preventing forking of blockchain is shown, which is proposed based on the following assumptions for blockchain architecture.

[0061] First, everyone knows that the entire blockchain is determined and identified by a Genesis block (which is hereafter defined as B.sub.0), including the numerical value of its Genesis block B.sub.0, rather than a particular storage location.

[0062] Second, at any time, there will be a set of several active nodes interacting with the public chain where they are located, and all active nodes have currently more reliable signature modes, such as key pairs. And assuming that most of these nodes are trusted nodes, these trusted nodes should actively respond to and support the protocol.

[0063] Third, all nodes in the set of active nodes can know the changes in the head of the blockchain and its vicinity, and except for the part of nodes that have just become active, all other good nodes in the set of active nodes can know the changes in the head and its vicinity.

[0064] Fourth, as a plurality of blocks become tamper-proof blocks, the tamper-proof property eventually becomes a consensus after a network-wide broadcast by notifying all nodes in the set of active nodes, nodes in the set of active nodes, and users who only pay attention to yet do not participate in the main chain can be notified about the blocks that become tamper-proof blocks, and the nodes and the users also know from each other that the other party has learned the above information.

[0065] Fifth, a node can leave or join the active nodes freely, the way of joining the active nodes is to know the numerical values of a plurality of blocks at the head of the blockchain, and the way of joining is the focus of the present invention, that is, how to determine that the joining corresponds to the real head of the main chain.

[0066] Sixth, once the node successfully identifies the real head information of the main chain, it may become familiar with all information and activities near the node and can accurately follow the development of the entire main chain.

[0067] The concept proposed based on the above assumptions attempts to implant an upward-pointing link. i.e., the backlink of the present invention, into the blockchain in the case where the existing blockchain has already held a conventional downward-pointing link. However, such implantation cannot be done at the expense of changing the existing blocks in the blockchain, which is neither desirable nor possible. For this purpose, some ingenious mechanisms are to be designed to accomplish the implantation of the backlinks by the nodes belonging to the same set that generated the preceding blocks without any features about the set or with observation only from an outside perspective of the blockchain. This practice is not entirely secure from the perspective of the trustworthiness of all the preceding nodes to a large extent, but can prevent forking of blockchain on a probabilistic basis.

[0068] This method is implemented by running a block creation algorithm with the following attributes in a blockchain environment under development.

[0069] I. The creator (miner or node) of each block is selected through a process in which the probability of the selected creator being an honest creator is assumed to be at least p, p being a value greater than 0.5.

[0070] II. It has been decided to use the following backlink protocol on a sequence of blocks B.sub.n (which may include all blocks) in conjunction with a parameters, in order to effectively determine, with the support of the backlink protocol, whether a case in which anyone of any s consecutive blocks is not one of the above sequences but is created by an honest creator is impossible (i.e., the probability of this case occurring is negative). Preferably, it is determined whether the probability that the number of blocks created by the honest creator in any s consecutive blocks is less than or equal to half of the total number of blocks is negative, i.e., impossible.

[0071] III. All participants know the selected sequence headed by the block B.sub.n.

[0072] Based on the above, the method comprises the following steps: S101, selecting s consecutive blocks B.sub.n to B.sub.n+s. According to the basic assumption of the blockchain, if the consecutive blocks are all located on the main chain of the blockchain, more than 50% of the blocks in the s consecutive blocks are created by trusted nodes. That is, the proportion of trusted nodes in all nodes create the s consecutive blocks is at least p, and the proportion of untrusted nodes is q, where q=1-p, the numerical values of p and q are unique and p>q; In consideration of blocks B.sub.n to B.sub.n+s, a link is created therebetween, under which B.sub.n actually proves B.sub.n+s, and each block of B.sub.n+1 . . . B.sub.n+s proves by the traditional blockchain link. A node that creates B.sub.n is named A.sub.n; S102, the node A.sub.n that creates the block Bn in the consecutive s blocks generates a key pair for the block B.sub.m, wherein the block B.sub.n contains a public key PK.sub.n in the key pair, and a private key PK′.sub.n in the key pair is held individually by the node A.sub.n; S103, holding the node A.sub.n active in a process of continuous generation of blocks B.sub.n+1 to B.sub.n+s in the blockchain. That is, the node has always been participating in the constriction of the blockchain, and will not become a zombie node, until the block B.sub.n+s in the s consecutive blocks becomes a tamper-proof block; S104, in response to the block B.sub.m, in the s consecutive blocks becoming a tamper-proof block, using the private key PK′.sub.n to sign on the block B.sub.n+s; S105, in response to the subsequent generation of a block B.sub.m in the blockchain, placing the signature in the block B.sub.m, where m>n+s; S106, forming a plurality of backlinks associated with a block size of the blockchain, when the generation node for each of the s consecutive blocks has completed the above steps. Since the signature is obtained by signing the block B.sub.n+s using the private key in the key pair of the block B.sub.m generated by node A, the access to the block B.sub.m actually includes the verification of the link from the block B.sub.m to the block B.sub.m+, thereby ensuring that the growth of the blockchain is performed on the main chain, and that each block is proved by an earlier block; S107, when a new chain claiming to be on the legitimate main chain of the blockchain is received, determined by a newly added node whether the blockchain forks according to the pattern and number of the backlinks. The pattern of the so-called backlinks is the specific link form of the backlink realized through the loop of steps S101-S105, and those skilled in the art should be well aware that, according to the existing architecture of the blockchain, it is necessary to first determine whether the new block belongs to a legitimate blockchain before determining whether the new block belongs to the head of the forked chain of the blockchain, and if the new block does not belong to blocks on the legitimate blockchain, it is unnecessary to perform the subsequent determination. The so-called legitimate blockchain includes the main chain and the forked chain derived from the same blockchain, and if the new block does not belong to the legitimate blockchain, it is meaningless to distinguish whether it is on the main chain or on the forked chain. The determination of this embodiment in this regard is based on the following structural characteristic of the blockchain; a blockchain is formed by a data structure in which blocks containing transaction information is sequentially linked from back to front, and each block points to a preceding block, and each block head contains a hash value of its preceding block, so that a chain that can trace back to the first block (the Genesis block) is created. According to the characteristics of the tree structure, it is determined whether the new block is located on a legal block chain by judging whether the new block finally points to the genesis block of the block chain through the traditional block chain link. In the affirmative case, the new block is located on the legitimate blockchain, or otherwise does not belong to the legitimate blockchain. Those skilled in the art may surely make a determination by other reasonable means in compliance with the characteristics of the blockchain architecture in the prior art.

[0073] For a block located on a legitimate blockchain, whether it is located on a forked chain is determined by determining the number of backlinks, which comprises: in case there are L backlinks in any s consecutive blocks of the new chain, in response to the condition that G>s/2 and only if L s/2, determining the blockchain to be the main chain that does not fork; in response to the condition that 1 Gs/2, and only if L>s-G, determining blockchain to be the main chain that does not fork; in response to the condition that L<G, determining the blockchain to be a forked chain; and in response to the condition that GLs-G, determining that it cannot be decided whether forking occurs, and other types of evidence are also required for determination, wherein G represents a minimum number of trusted nodes in the s consecutive blocks.

[0074] A schematic diagram of a single backlink formed according to the above method is shown in FIG. 2, which, for the sake of clarity, only shows the backlink relationship contained among three nodes with relatively short spacing, which reduces or eliminates the number of keys previously required.

[0075] In some embodiments, node A.sub.n uses only once the private key PK′.sub.n, and a key pair for each of the s blocks B.sub.n to B.sub.n+s is regenerated.

[0076] In some embodiments, the public key is generated based on a hash signature algorithm, and the hash signature algorithm comprises a Lamport algorithm.

[0077] In some embodiments, the method further comprises placing the signature in a location other than the block B.sub.n+s of the blockchain to ensure that the signature can be placed in the block B.sub.m in the S105.

[0078] In some embodiments, the signature is deposited as a transaction in the blockchain. Because the signature is “transformed” to form the transaction and placed on the blockchain, the existing mechanism cannot ensure that the transaction as a signature will certainly become tamper-proof along with other ordinary transaction data within the same time range. If not guaranteed by a certain delay mechanism, the transaction may be discarded, so it is usually used together with a certain delay mechanism.

[0079] In some embodiments, the signature is copied to obtain a copied signature, and both the signature and the copied signature are stored on the blockchain.

[0080] In some embodiments, the legitimacy of the signature is checked before execution of the S105, and the signature passing the legitimacy check proceeds to be executed with the S105, while the signature not passing the legitimacy check is considered by the blockchain as an illegitimate signature, and thereby is refused to executed with the S105.

[0081] For the execution of S104, using the private key to sign the transaction block is the only security shield, and there is no server-side security assurance. A signature is just a means of control. If the signature process is not incorporated into the TEE enclave environment for execution, there is no system security at all. Therefore, the implementation of the entire method is ensured to take place in a trusted execution environment to construct a secure enclave environment so that a trusted root can be provided in a trusted computing field to provide security assurance for resident programs and data. The private key stored in the TEE, even the program of the method involved in the present invention can never be leaked out of the enclave nor can be derived for cracking analysis, so that the execution process (especially when invoking the input and output) also has security guarantees. Because cracking a program residing in the TEE is generally considered difficult, it is possible to choose the TEE device to fix the vendor number and serial number in order to uniquely identify the device.

[0082] In some embodiments, the blockchain is a public chain.

[0083] In some embodiments, a Genesis block of the blockchain is fully trusted, wherein a node of the Genesis block or a node of another block authorized by the Genesis block establishes a first backlink for the Genesis block, and after the first backlink appears, a probability of forking occurring within the s consecutive blocks covered by the first backlink is zero. This is because for any block within B.sub.0 to B.sub.s it is first determined that a new node can be traced back to B.sub.0 by tracing the parent block hash from B.sub.n and then it is uniquely determined that B.sub.0 to B.sub.s are on the main chain because the backlink of B.sub.0 uniquely proves that B.sub.s is its own legitimate successor block.

[0084] In some embodiments, determination of whether a new block is a head on the forked chain cannot be achieved in a case where a small amount of blocks exist at a head and tail of the blockchain, the method comprises: In the first way, the new block is at a position of a closest suspected fork point, all blocks before the new block are in the main chain, and a node creating the new block has not formed and placed a complete backlink in the blockchain, performing a short-term signature on a block or a block sequence that has been tamper-proof in successor blocks of the new block, and placing the short-term signature in one or more storage positions, so that when a number of successor blocks that have backlinks of the new block is less than s, if the short-term signature is not in real-time or expired, the short-term signature is used instead of the backlinks for determination; determining that the new block is on the forked chain in response to the short-term signature being absent or expired; or the second method is to continue to wait until a sufficient number of backlinks are formed from a block to be determined, wherein the number can be flexibly defined according to the application scenario of the blockchain, and is usually several hundreds or even more in scale. For the first manner, the specific implementation of the embodiment is to assume that B.sub.i is the closest suspected forking point that can be confirmed, that is, all the leading blocks of the block are on the main chain. A block creation node A.sub.j(i-js) before the block has not placed its backlinks in the blockchain, and the protocol requires that these nodes continue to focus on the growth of the blockchain, perform a short-term signature on a block or a block sequence that has been tamper-proof in its successor blocks, and place the short-term signature in some storage position (e.g., the transaction pool). By extending the above method, when the number of subsequent blocks of B.sub.i is less than s, if the short-term signature is not in real-time or expired, the short-term signature can be used to replace the original backlink for determination. If these short-term signatures do not exist or expire, it can be judged that B.sub.i is on the forked chain. The determined storage location may be a transaction pool, and the transaction pool is searched for a clue as to whether the block has become a tamper-proof block on the main chain while searching for a backlink. The transaction pool stores short-term signature information that has been signed. The short-term signature information is confirmation information that identifies a blockchain head location provided by a node that does not provide a backlink, and whether the block is a head on a forked chain is determined by accessing the short-term signature information in the transaction pool. In this embodiment, for example, whether the block is a block on the main chain of the blockchain can be determined by counting the voting information included in the short-term signature, and if more than 50% of voting information included in the short-term signature determines that the block is a block on the main chain, the block is identified to be a block on the main chain and accepted; otherwise, the new block is determined as a block on the forked chain. The purpose of this setup is to try to find more evidence about whether the new block is a head of the forked chain as a supplement, and a duplicate signer will use one public key to sign two blocks. Thus, while exposing his identity, he also exposes the new block generated on the forked chain, which in turn will reflect the location of the forked chain.

[0085] Referring to FIG. 4, the blockchain includes tamper-proof blocks 41 on the main chain, blocks 42 with illegitimate double links, blocks 43 without a link on the forked chain, and blocks 44 with a link on the forked chain. Most of the tamper-proof blocks 41 have formed a complete backlink 45, however, a part of blocks that are close to the head have only completed the formation of the key pair and the formation of the partial signature, and still have not reached a time node of performing a second signature (i.e., step S105) after computations, thereby forming a calculated but unplaced link 46. Even some blocks that are closer to the head have not formed an available link, i.e., have formed an unavailable link 47. Those blocks that are close to the head, whether on the forked chain or the main chain, are referred to as temporary blocks 48.

[0086] FIGS. 5 to 8 illustrate in detail the two situations that occur in FIG. 4, respectively.

[0087] In FIG. 5, there are always three link forms associated with backlinks throughout the blockchain, i.e., complete backlinks 45, calculated but unplaced links 46, and unused links 47.

[0088] FIG. 6 describes a case where the method is executed only to step S104, that is, blocks B.sub.n to B.sub.n+s have been formed, but blocks after B.sub.n+s have not been generated, or only several blocks have been generated, and block B.sub.m has not been generated. In this case, the blockchain is in two states at the same time; a state 61, in which the public key material is located in B.sub.n; and state 62, in which the signature/link is still located outside the blockchain, and the signature is not checked yet. Therefore, the short-term signature verification mode in the first manner is executed, in which case the short-term signature may be located in the transaction pool. Of course, the second waiting manner may also be adopted.

[0089] FIG. 7 describes a case where the method is executed only to step S102, that is, blocks B.sub.n to B.sub.n+s have been formed, but B.sub.n+s has not become a tamper-proof block, let alone the generation of block B.sub.m. In this case, the blockchain is in three states at the same time; a state 71, in which the current block B.sub.m becomes a tamper-proof block; a state 72, in which the public key in the block B.sub.m is unavailable; and a state 73, in which B.sub.n+s is generated, but an untamperable block has not yet been formed, so that backlinks have not formed available backlinks. In fact, the state under FIG. 7 is a state corresponding to a point just previous to that of the state under FIG. 6. Therefore, it is still necessary to perform the short-term signature verification mode under the first manner, in which case the short-term signature may be located in the transaction pool. Of course, the second waiting manner can also be adopted.

[0090] FIG. 8 describes a case where the method is executed only to step S101, that is, B.sub.n has not been generated. In this case, blocks B.sub.n to B.sub.n+s have not become tamper-proof blocks, that is, block B.sub.m has not been generated yet. In this case, the blockchain is in two states at the same time; a state 81, in which the current block B.sub.m has not been generated; and a state 82, in which the public key material has not been formed, the key pair has also not been formed, and in this case, there is no available backlink. In fact, the state under FIG. 8 is a state corresponding to a point earlier than that of the state under FIG. 7. Therefore, it is still necessary to perform the short-term signature verification mode under the first manner, in which case the short-term signature may be located in the transaction pool. Of course, the second waiting manner can also be adopted.

[0091] FIG. 9 shows a backlink pattern formed in a case where a complete backlink 45, a calculated but unplaced link 46 (i.e., where the block B.sub.m has not occurred), and an unused link 47 (i.e., where the block B.sub.n+s has not occurred) exist simultaneously on a main chain of the blockchain after the formation of the backlink mechanism. Among the above, the public key material exists on each block of a sequence of selected s blocks and on the blocks on the main chain generated thereafter, that is, the creator of each block generates a corresponding key pair. In other words, a complete backlink portion (indicated by a solid arrow) only exists on block B.sub.m (the 6th block in this implementation) formed at the first execution of S105 and on subsequent blocks on the main chain, and a signature (indicated by a dotted arrow in the figure) placed without being checked also exists in the blockchain structure. In this case, the short-term signature verification mode under the first manner may be performed, in which case the short-term signature may be located in the transaction pool. Of course, the second waiting manner can also be adopted.

[0092] In some embodiments, the method further comprises performing a search on a chain portion other than the main chain to confirm whether there exists a duplicate signer that performs a duplicate signature on the backlinks, wherein the duplicate signer represents a plurality of nodes that perform signature on two blocks to be generated, and the two blocks to be generated are respectively on the main chain and the fork, so that the fork is found according to a block generated by the duplicate signer.

[0093] In some embodiments, for a suspected forked chain, by comparing a main chain before the suspected forked chain with a chain structure formed by the backlink after an intersection of the suspected forked chain, if there is a significant difference between the main chain before the suspected forked chain and the chain structure formed by the backlink of the chain after the intersection of one of the suspected forked chains, the suspected forked chain is determined to be a forked chain, or otherwise determined to be the main chain. Specifically, for the suspected forked chain, a main chain portion before the suspected forked chain and a chain structure after an intersection of the suspected forked chain and the main chain are compared, wherein the main chain comprises the backlinks, and if a comparison result shows a significant difference in the number of the backlinks, the suspected forked chain is determined to be a forked chain, or otherwise the suspected forked chain is determined to be a main chain. Of course, those skilled in the art may also not have to calculate a specific number of backlinks so as to save computing resources, but make a straightforward comparison of the data scale of the backlinks on the chain structure.

[0094] In some embodiments, in response to using the private key PK′.sub.n to sign on the block B.sub.n+s the private key PK′.sub.n is deleted to prevent it from being abused.

[0095] After the backlink mechanism is embedded in the blockchain, we test one block (defined as block B). The content of the test is the execution of the algorithm logic, wherein the algorithm logic includes: (1) all hash pointers are traced back to their respective root nodes, i.e., the Genesis block B.sub.0. If the hash pointers are not traced back to the Genesis block, the block B is determined not to be a part of the blockchain; and (2) for externally determined constants r and s, it is set that the block B is at the m-th level, then for a block B.sub.n+s (n+s<m-r), the block B.sub.n+s is signed by using the private key corresponding to the public key included in the block B.sub.m, where the constant r means waiting for at least r blocks, so that the signature can be included in the subsequent block. Here, the numerical range of r is agreed in advance by all the included nodes involved in the blockchain according to factors such as the generation speed of the block and the packing speed of the transaction. For example, the determined backlink must be generated within 20 blocks, so that the block generation range when the backlink is determined, and the verification of the backlink is completed, thereby improving the operability of the method.

[0096] The two logics of the algorithm are also verification logics. If at least one of the two verification logics fails, the verifier (i.e., the corresponding node) can determine that block B is not part of the main chain if the protocol follows the assumption that the main chain starts from the Genesis block.

[0097] This method possesses complete security and prevents forking. In the above embodiment, the generation sequence of blocks is B.sub.n, B.sub.n+s B.sub.m, to B.sub.m, so as to clarify the actual physical meaning of the backlink, that is, the signature of the block B.sub.n+s by the private key corresponding to the public key in the block B.sub.n reveals the unique true inheritance relationship between the two blocks, and the backlink is actually included in the r blocks after the block B.sub.n+s, so as to reveal the assumption related to the timestamp and ensure the authenticity and certainty of the verification. Therefore, according to the generation rule of the backlink, by taking a block that is r blocks ahead of the current block as a boundary, the generated blockchain can be guaranteed not to fork.

[0098] The method is performed on the premise that there should be s independent backlink overlays on every consecutive pair of blocks in the central portion of the blockchain, but the situation at the head and tail of the blockchain has a different appearance due to the insufficient number of forward and backward blocks, in which case a short fork phenomenon can easily occur.

[0099] Similarly, in a case where the number of blocks existing at the initial portion of the blockchain is less than s, the backlink mechanism cannot be initiated at all, and of course, when s is small, a long fork cannot be created.

[0100] For the above two cases, in some embodiments, when the number of blocks existing at the head and tail of the blockchain is small, one method is to continue when determining whether a block is a head on the forked chain, continuously waiting until a sufficient number of backlinks are formed from the block to be determined, and another method comprises searching the transaction pool for a clue as to whether the block is a block on the main chain while searching the blocks for backlinks. The information stored in the transaction pool is signed copied information provided by a plurality of nodes that do not provide backlinks with respect to the position of the head of the blockchain, and the copied information is accessed through the transaction pool for determination without storing the copied information in the chain, and the signature does not need to be a long-term signature.

[0101] Referring again to FIG. 3, particularly in a case where the value of s is small, bad nodes control a sufficient number of blocks that have been mined, making it more difficult to distinguish between the main chain and the forked chain. Therefore, the number of blocks involved in the related operation in the Genesis blocks also needs to be set according to the requirements of the system application. According to the general rules, it is assumed that the backlink detection protocol is set in every s consecutive block, having at least L desired signatures, and that the blockchain can be identified as an official chain or the main chain only after forming L backlinks. If the value range of L is not properly limited, the following two cases may occur; (L) false positive; the protocol identifies a blockchain that wrongly forks as the official chain or the main chain; (2) false negative; because the attacker attempts to limit the number of signatures to less than L, no L backlinks are formed, thus the protocol refuses to accept the real official chain or main chain.

[0102] Selecting the value range of L can avoid the simultaneous appearance of the above two cases. The assumption that an honest node providing a signature must provide the signature as soon as possible within the time defined by the protocol and that the provided signature is immediately received by the blockchain establishes on the basis that the constant r is selected to be large enough and at least one honest miner will comply with the protocol and include the signature in the block. Setting the minimum number of honest nodes in the s contiguous blocks to G, if L>G, and if no signature is provided by the bad miner, a false negative will occur according to the protocol. If L is less than or equal to the maximum number s-G of bad miners, according to the protocol, it is very easy for bad miners to generate forks, which results in the occurrence of a false positive. Therefore, the value range of L should be between s-G and G, i.e., s-G<LG, and G>s/2.

[0103] There is a typical game process for the attack on non-honest or bad nodes. First, these nodes need to make clear their own proportion in the s consecutive blocks, and know each other's existence, and reach cooperation, so as to determine the success probability in forking before the miner's fee or deposit losses caused by not providing a signature. And these bad nodes can also forge timestamps so that the honest nodes cannot perceive the forked node until it is broadcasted to the entire network. Because of the existence of the game, the attacker is also caught in a dilemma. On one hand, a normal participation in the generation and development of the main chain can obtain an expected income, but at the same time, the attacker needs to disguise himself to wait for the opportunity to fork. When the attacker should publish the signature yet refrain from doing so, in addition to economic losses, in fact, the attacker also exposes himself to the probability and identity that he may become a dishonest node, so that he may be found before the act of forking, which leads to failure. The dishonest node's motivation to do evil is lost, thus the dishonest node is pushed toward the direction of not doing evil on the public chain. In addition, the defense mechanism is mainly used to prevent long forks, where participants have a longer time to organize defense and impose punishment. If the selected s is large, the time waiting for ensuring whether the s blocks are on the main chain will be longer, and the miner will have to spend more time waiting. However, on the premise that no additional number of signatures is required (that is, one miner still provides one signature), this is still worthwhile with respect to the security against forking brought to the blockchain.

[0104] In some embodiments, forking is found by searching other chains for duplicate signers (i.e., a plurality of nodes signing two blocks to be generated) of a backlink.

[0105] In some embodiments, for a small portion (which, depending on the application scenario of the blockchain, is usually several or dozens in number) of suspected forked chains that are not determined to be official chains yet, by comparing the composition of the chains after the intersection of the two chains, if there is a great difference in the composition of one of the two chains after the intersection, it can be determined to be a forked chain, or otherwise it can be determined to be an official chain (i.e., the main chain).

[0106] FIG. 10 shows a schematic structural diagram of a device for preventing forking of blockchain according to an exemplary embodiment of the present disclosure. As shown in FIG. 10, the device for preventing blockchain forks includes a blockchain 1001 and a processor 1002, wherein the blockchain 1001 is capable of ensuring that information published thereon is tamper-proof. It is well known that the blockchain is a chained data structure formed by connecting data in chronological order in a series of blocks, and is also a tamper-proof and unforgeable distributed ledger that cryptographically guarantees data. Blockchain uses cryptography such as hash and signature and consensus algorithm to build a trust mechanism, which makes the cost of repudiation, tampering, and fraud huge and ensures data is tamper-proof and unforgeable. It may be realized that the blockchain may be implemented in any manner known in the art or known in the future, such as Bitcoin, Ethereum, etc. The processor 1002 may be used for the following.

[0107] Selecting s consecutive blocks B.sub.n to B.sub.n+s. According to the basic assumption of the blockchain, if the consecutive blocks are all located on the main chain of the blockchain, more than 50% of the blocks in the s consecutive blocks are created by trusted nodes, that is, the proportion of trusted nodes in all nodes creating the s consecutive blocks is at least p, and the proportion of untrusted nodes is q, where q=1-p, the numerical values of p and q are unique and p>q; In consideration of blocks B.sub.n to B.sub.n+s, a link is created therebetween, under which B.sub.n actually proves B.sub.n+s, and each block of B.sub.n+s . . . B.sub.n+s−1 is proven by the traditional blockchain link. A node that creates B.sub.n is named A.sub.n; generating, by the node A.sub.n that creates the block B.sub.m in the s consecutive blocks, a key pair for the block B.sub.m, wherein the block B.sub.m contains a public key PK.sub.n in the key pair, and a private key PK′.sub.n in the key pair is held individually by the node A.sub.n; holding the node A.sub.n active in a process of continuous generation of blocks B.sub.n+1 to B.sub.n+s in the blockchain, that is, the node has always been participating in the construction of the blockchain, and will not become a zombie node, until the block B.sub.n+s in the s consecutive blocks becomes a tamper-proof block; in response to the block B.sub.n+s in the s consecutive blocks becoming a tamper-proof block, using the private key PK′.sub.n to sign on the block B.sub.n+s; in response to subsequent generation of a block B.sub.m in the blockchain, placing the signature in the block B.sub.m, and forming a plurality of backlinks associated with the block size of the blockchain, when the generation node for each of the s consecutive blocks has completed the above steps, where m>n÷s. Since the signature is obtained by signing the block B.sub.n+s using the private key in the key pair of the block B.sub.n generated by the node A, the access to the block B.sub.m actually includes the verification of the link from the block B.sub.m to the block B.sub.n+s, thereby ensuring that the growth of the blockchain is performed on the main chain, and that each block is proved by an earlier block; when a new chain claiming to be on the legitimate main chain of the blockchain is received, determined by a newly added node whether the blockchain forks according to the pattern and number of the backlinks. The pattern of the so-called backlinks is the specific link form of the backlink realized through the loop of the steps implemented previously, and those skilled in the art should be well aware that, according to the existing architecture of the blockchain, it is necessary to first determine whether the new block belongs to a legitimate blockchain before determining whether the new block belongs to the head of the forked chain of the blockchain, and if the new block does not belong to blocks on the legitimate blockchain, it is unnecessary to perform the subsequent determination. The determination of this embodiment in this regard is made according to the following structural characteristic of the blockchain; a blockchain is formed by a data structure in which blocks containing transaction information is sequentially linked from back to front, and each block points to a preceding block, and each block head contains a hash value of its preceding block, so that a chain that can trace back to the first block (the Genesis block) is created. According to this tree structure characteristic, whether the new block is located on a legitimate blockchain can be determined by determining whether the new block can eventually point to the Genesis block of the blockchain through the traditional blockchain link, that is, whether the current blockchain structure meets the basic tree structure characteristic. Those skilled in the art may surely make a determination by other reasonable means in compliance with the characteristics of the blockchain architecture in the prior art.

[0108] For a new chain located on a legitimate blockchain, whether it is located on a forked chain is determined by determining the number of backlinks, which comprises: in case that there are L backlinks in any s consecutive blocks of the new chain, in response to the condition that G>s/2 and only if Ls/2, determining the blockchain to be a main chain that does not fork; in response to the condition that 1Gs/2, and only if Los-G, determining the blockchain be a main chain that does not fork; in response to the condition that L<G, determining the blockchain to be a forked chain; and in response to the condition that GLs-G, determining that it cannot be decided whether forking occurs, and other types of evidence are also required for determination, wherein G represents a minimum number of trusted nodes in the s consecutive blocks.

[0109] In some embodiments, the node A.sub.n uses only once the private key PK′.sub.n, and a key pair for each of the s blocks B.sub.n to B.sub.n+s is regenerated.

[0110] In some embodiments, the public key is generated based on a hash signature algorithm, and the hash signature algorithm comprises a Lamport algorithm that can only be signed once using a private key.

[0111] In some embodiments, the processor 1002 is further configured to place the signature in a location other than block B.sub.n+s of the blockchain to ensure that in response to the subsequent generation of a block B.sub.m in the blockchain, the signature can be placed in the block B.sub.m.

[0112] In some embodiments, the processor 1002 is configured to deposit the signature as a transaction in the blockchain.

[0113] In some embodiments, the processor 1002 is configured to copy the signature to obtain a copied signature and store both the signature and the copied signature on the blockchain.

[0114] In some embodiments, the processor 1002 is configured to check the legitimacy of the signature before signing the block B.sub.n+s using the private key PK′.sub.n in response to the block B.sub.n+s in the s consecutive blocks becoming a tamper-proof block, wherein the signature passing the legitimacy check proceeds to be executed with placing the signature in the block B.sub.m, while the signature not passing the legitimacy check is considered by the blockchain as an illegitimate signature, and thereby is refused to be executed with placing the signature in the block B.sub.m.

[0115] In some embodiments, the signature process is performed in a trusted execution environment.

[0116] In some embodiments, the blockchain is a public chain.

[0117] In some embodiments, a Genesis block of the blockchain is fully trusted, wherein a node of the Genesis block or a node of another block authorized by the Genesis block establishes a first backlink for the Genesis block, and after the first backlink appears, a probability of forking occurring within the s consecutive blocks covered by the first backlink is zero. This is because for any block within B.sub.0 to B.sub.s it is first determined that a new node can be traced back to B.sub.0 by tracing the parent block hash from B.sub.s, and then it is uniquely determined that B.sub.0 to B.sub.s are on the main chain because the backlink of B.sub.0 uniquely proves that B.sub.s is its own legitimate successor block.

[0118] In some embodiments, when determination of whether a new block is a head on the forked chain cannot be achieved in a case where a small amount of blocks exist at a head and tail of the blockchain, the processor 1002 is configured to implement; a first method in which the new block is at a position of a closest suspected forking point, all blocks before the new block are in the main chain, and a node creating the new block has not formed and placed a complete backlink in the blockchain, comprising performing a short-term signature on a block or a block sequence that has been tamper-proof in successor blocks of the new block, and placing the short-term signature in one or more storage positions, so that when a number of successor blocks that have backlinks of the new block is less than s, if the short-term signature is not in real-time or expired, the short-term signature is used instead of the backlink for determination; and determining that the new block is on the forked chain in response to the short-term signature being absent or expired; or a second method, comprising continuously waiting until a sufficient number of backlinks are formed from a block to be determined, wherein the number can be flexibly defined according to the application scenario of the blockchain, and is usually several hundreds or even more in scale. For the first method, a specific implementation of the embodiment is to assume that B.sub.i is the closest suspected forking point that can be confirmed, that is, all the leading blocks of the block are on the main chain. A block creation node A.sub.j (i-js) before the block has not placed its backlinks in the blockchain, and the protocol requires that those nodes continue to focus on the growth of the blockchain, perform a short-term signature on a block or a block sequence that has been tamper-proof in its successor blocks, and place the short-term signature in some storage position (e.g., the transaction pool). By extending the above method, when the number of subsequent blocks of B.sub.i is less than s, if the short-term signature is not in real-time or expired, the short-term signature is used instead of an original backlink for determination. If, on the contrary, these short-term signatures do not exist or expire, B.sub.i can be determined to be located on the forked chain. The determined storage location may be a transaction pool, and the transaction pool is searched for a clue as to whether the block has become a tamper-proof block on the main chain while searching for a backlink. The transaction pool stores short-term signature information that has been signed. The short-term signature information is confirmation information that identifies the blockchain head location provided by a node that does not provide a backlink, and whether the block is a head on a forked chain is determined by accessing the short-term signature information in the transaction pool. In this embodiment, for example, whether the block is a block on the main chain of the blockchain can be determined by counting voting information included in the short-term signature, and if more than 50% of voting information included in the short-term signature determines that the block is a block on the main chain, the block is identified to be a block on the main chain and accepted; otherwise, the new block is determined as a block on the forked chain. The purpose of this setup is to try to find more evidence as to whether the new block is a head of the forked chain as a supplement, and a duplicate signer will use a public key to sign two blocks, thus exposing his identity while exposing the new block generated by himself on the forked chain, which in turn will reflect the location of the forked chain.

[0119] In some embodiments, the processor 1002 is further configured to perform a search on a chain portion other than the main chain to confirm whether there exists a duplicate signer that performs duplicate signature on the backlink, wherein the duplicate signer represents a plurality of nodes that perform signature on two blocks to be generated, and the two blocks to be generated are respectively on the main chain and the forked chain, so that the forked chain is found according to a block generated by the duplicate signer.

[0120] In some embodiments, the processor 1002 is configured to compare, for a suspected forked chain, a main chain portion before the suspected forked chain and a chain structure after an intersection of the suspected forked chain and the main chain, wherein the main chain comprises the backlinks, and if a comparison result shows a significant difference in the number of the backlinks, the suspected forked chain is determined to be a forked chain, otherwise, the suspected forked chain is determined to be a main chain.

[0121] In some embodiments, the processor 1002 is configured to delete, in response to using the private key PK′.sub.n to sign on the block B.sub.n+s the private key PK′.sub.n to prevent it from being abused.

[0122] Thus, the method ensures that the previous transaction page in the blockchain restricts the subsequent transaction page. Because the number of blocks in this mechanism is selected to be large enough, the basic assumption of blockchain is satisfied, that is, the number of malicious bookkeepers is small, so the number of link ropes that can be migrated to the forged ledger at the back end is small. Thus, the verification on the number of backlinks in the method cannot be passed, and a fork cannot be successfully forged.

[0123] In one aspect of the present disclosure, there is further provided a machine-readable storage medium on which a computer program is stored, wherein the computer program, when executed by a processor, implements the method for preventing forking of blockchain as described above. The technical solution of the method for preventing forking of blockchain has been described in detail above, and is not repeated herein. In some embodiments, the machine-readable storage medium is a tangible component of a digital processing device. In other embodiments, the machine-readable storage medium is optionally removable from a digital processing device. In some embodiments, by way of non-limiting example, the machine-readable storage medium may include a USB disk, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a flash memory, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), a solid state memory, a magnetic disk, an optical disk, a cloud computing system or a service, or the like.

[0124] It should be understood that the steps described in the method embodiment of the present disclosure may be performed in a different order and/or in parallel. Further, the method embodiment may include additional steps and/or omit the steps shown in implementation. The scope of the invention is not limited in this respect.

[0125] A number of specific details are described in the specification provided herein. However, it should be understood that embodiments of the present disclosure may be practiced without these specific details. In some embodiments, well-known methods, structures, and techniques are not shown in detail so as not to obscure the understanding of this specification.

[0126] Although exemplary embodiments of the present invention have been shown and described herein, it will be readily understood by those skilled in the art that such embodiments are provided by way of example only. Many modifications, changes and alternatives will now occur to those skilled in the art without departing from the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in the practice of the invention. The following claims are intended to limit the scope of the invention and thus cover the methods and structures within the scope of these claims and their equivalents.