Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other examples obtained based on the examples in the present invention are within the scope of the present invention.
The consensus mechanism is a core feature of the blockchain and is a scheme for ensuring consistency of the blockchain system under a distributed architecture. Currently, there are also a number of consensus algorithms in the mainstream: proof of workload (Proof of Work, abbreviated as POW), Proof of rights and interests (Proof of stamp, abbreviated as POS), Proof of authorized equity (freed Proof of stamp, abbreviated as DPOS), Practical Byzantine Fault Tolerance (PBFT), and the like. For example, the POW relies on the machine to perform mathematical operation to obtain the accounting right, the resource consumption is higher than that of other consensus mechanisms, the monitorability is weak, meanwhile, the consensus is achieved every time, the operation needs to be jointly participated in by the whole network, the performance efficiency is lower, and 50% of nodes in the whole network are allowed to make errors in the fault tolerance. The POS has the main idea that the difficulty in obtaining the node accounting right is in inverse proportion to the rights and interests held by the nodes, compared with the PoW, the resource consumption caused by mathematical operation is reduced to a certain extent, the performance is correspondingly improved, but the method still obtains the accounting right based on Hash operation competition, and the supervision performance is weak. The consensus mechanism is the same fault tolerance as PoW. The method is an upgrading consensus mechanism of the Pow, and the ore excavation difficulty is reduced in equal proportion according to the proportion and time of token tokens occupied by each node, so that the speed of finding random numbers is increased. DPOS is authenticated and billed by agents by electing several agents. Its compliance supervision, performance, resource consumption and fault tolerance are similar to PoS. Similar to the board voting, the bearer throws a certain number of nodes, and the agent verifies and bills. However, when the block chain consensus is performed by the method, even if other witnesses receive the current new block, the new block cannot be confirmed, and the previous block can be confirmed by the production block only when the witness turns to the block output, so that the confirmation of the new block needs 45 seconds, and the efficiency is low. In order to solve the above technical problem, the present invention provides a block chain consensus method, apparatus, device and computer readable storage medium.
It should be noted that the method, apparatus, device, and computer-readable storage medium for block chain consensus provided in the present application may be applied in any scenario of block chain consensus.
Fig. 1 is a schematic flow chart of a block chain consensus method according to an embodiment of the present invention, as shown in fig. 1, the method includes:
step 101, receiving a consensus request initiated by a main node, wherein the consensus request is broadcasted to a block chain after the main node signs a signature through a private key of the main node, and each main node continuously produces a preset number of blocks;
102, verifying the consensus request through a pre-stored public key of the main node, and sending verification information according to a verification result, wherein the verification information comprises confirmation information and suspicion information;
and 103, if the number of the confirmation information is detected to exceed a preset threshold value, generating a new block according to the consensus request.
In this embodiment, when the master node wants to generate a new tile, the master node may initiate a consensus request, encrypt the consensus request by using a private key of the master node itself, and broadcast the encrypted consensus request to the tile chain, so that all other nodes in the tile chain can receive the consensus information. Accordingly, nodes in the block chain except the master node may receive the consensus request, and in order to improve the block output efficiency of the block chain, the consensus request may be checked after being received. In order to ensure the validity of the consensus request, the consensus request can be verified through a preset public key of the main node, audit information is sent according to a verification result, wherein the audit information comprises confirmation information and doubtful information, and the audit information is broadcasted to the block chain, so that all other nodes in the block chain can receive the audit information. Accordingly, if it is detected that the number of currently received acknowledgement messages exceeds a preset threshold, the preset threshold may be set according to an actual situation, for example, the preset threshold may be two thirds of all nodes in the block chain. If the number of the currently received confirmation information is detected to exceed the preset threshold, most nodes in the representation block chain represent confirmation to the consensus request, namely the consensus is achieved, and at this time, a new block can be generated according to the consensus request. It should be noted that network delay often affects the speed of block generation, for example, a 0.5 second acknowledgement time often results in the next block generator not receiving the block of the previous block generator and generating the next block, and the next block generator ignores the previous block, resulting in a split block chain (two blocks at the same block height). Therefore, in order to reduce the impact of network delay on the block-out speed, each master node may be specified to continuously produce a preset number of blocks, which exceeds a preset minimum threshold and is greater than a preset maximum threshold. That is, each witness is also responsible for the previous block production, but changes from the first 1 produced only to N produced. In the worst case, the last or two of the N blocks may be skipped by the next witness due to network delay or other unexpected reasons, but the first ones of the N blocks will have sufficient time to pass to the next witness. The whole network broadcasting is carried out immediately after each block is produced, and the block producer waits for 0.5 second to produce the next block and receives the confirmation result of other visitors to the previous block. The production of the new block and the receipt of the old block acknowledgement are performed simultaneously. In most cases, the transaction will be confirmed (irreversible) within 1 second. This includes 0.5 seconds of block production and the time required for other witness confirmation. Under the common identification mechanism, when each node generates a new block, the whole network still broadcasts, after other nodes receive the new block, the block is immediately verified, the block with the verified signature is immediately returned to the block outlet node of the new block, and the new block is confirmed without waiting for the other nodes to generate the new block. From the current out-of-block node perspective, the node produces a block and broadcasts throughout the network, and then receives confirmation of the block from other nodes, and at the instant of receiving 2/3 the block (including the transaction therein) is irreversible.
In the block chain consensus method provided by this embodiment, a consensus request initiated by a master node is received, where the consensus request is broadcasted to a block chain after the master node signs a signature with its own private key, and each master node continuously produces a preset number of blocks; verifying the consensus request through a prestored public key of the main node, and sending verification information according to a verification result, wherein the verification information comprises confirmation information and suspicion information; and if the number of the confirmation information exceeds a preset threshold value, generating a new block according to the consensus request. By immediately auditing according to the consensus request after receiving the consensus request, and outputting the block when the confirmation information exceeds a preset threshold value, the block generation efficiency can be improved.
Fig. 2 is a schematic flow chart of a block chain consensus method according to a second embodiment of the present invention, where the method includes:
step 201, receiving a consensus request initiated by a master node, wherein the consensus request is broadcasted to a block chain after the master node signs through a private key of the master node, and each master node continuously produces a preset number of blocks;
step 202, judging the legality of the consensus request through a pre-stored public key of the main node;
step 203, if the consensus request is legal, broadcasting confirmation information into a block chain according to a verification result;
step 204, if the consensus request is illegal, broadcasting the suspect information to the block chain according to the verification result;
step 205, if it is detected that the number of the acknowledgement messages exceeds a preset threshold, generating a new block according to the consensus request.
In this embodiment, after the master node sends the consensus request, the nodes in the blockchain except for the master node may receive the consensus request, and in order to improve the block output efficiency of the blockchain, the consensus request may be checked after receiving the consensus request. In order to ensure the validity of the consensus request, the consensus request can be verified through a preset public key of the main node, and audit information is sent according to a verification result. Specifically, the validity of the consensus request may be determined by a pre-stored public key of the master node, and if the consensus request is determined to be valid, the confirmation information may be broadcast to the block chain according to the verification result, and correspondingly, if the consensus request is determined to be invalid, the doubtful information may be broadcast to the block chain according to the verification result. It is understood that before sending the verification result, each node may encrypt the verification result by its own private key and broadcast the encrypted verification result into the blockchain.
In the block chain consensus method provided in this embodiment, the validity of the consensus request is determined by a pre-stored public key of the master node, if the consensus request is legal, confirmation information is broadcast to the block chain according to a verification result, and if the consensus request is illegal, doubtful information is broadcast to the block chain according to the verification result, so that the validity of the consensus request can be ensured on the basis of improving the block chain block exit efficiency.
Fig. 3 is a schematic flow chart of a block chain consensus method according to a third embodiment of the present invention, where on the basis of any of the foregoing embodiments, as shown in fig. 3, the method further includes:
step 301, receiving a transaction request sent by an initiator, wherein the transaction request is broadcasted to a block chain after the initiator signs a signature through a private key of the initiator, and each master node continuously produces a preset number of blocks;
step 302, judging whether the initiator is a main node;
step 303, if yes, verifying the validity of the transaction request, if the transaction request is legal, storing the transaction request to a preset storage path, and if the transaction request is illegal, deleting the transaction request;
step 304, if not, forwarding the transaction request;
step 305, receiving a consensus request initiated by a master node, wherein the consensus request is broadcasted to a block chain after the master node signs through a private key of the master node;
step 306, verifying the consensus request through a pre-stored public key of the master node, and sending verification information according to a verification result, wherein the verification information comprises confirmation information and doubtful information;
and 307, if the number of the confirmation information is detected to exceed a preset threshold value, generating a new block according to the consensus request.
In this embodiment, when the initiator of the transaction in the blockchain initiates a transaction, the transaction request is broadcasted to the whole network after the transaction is signed by using the private key, and accordingly, other nodes in the blockchain can receive the transaction request. After receiving the transaction request, it is first necessary to determine whether the initiator of the transaction request is a preset master node, and if so, the validity of the transaction request may be verified. Specifically, the transaction request may be verified through a pre-stored public key of the initiator, and if the transaction request is verified to be legal, the transaction request may be stored to a preset storage path, and accordingly, if the transaction request is verified to be illegal, the transaction request may be directly deleted. In addition, if it is detected that the initiator of the transaction request is not the master node in the blockchain, the transaction request may not be verified, and the transaction request may be directly forwarded to the blockchain.
In the block chain consensus method provided by this embodiment, a transaction request sent by an initiator is received, where the transaction request is broadcast to a block chain after being signed by a private key of the initiator, and it is determined whether the initiator is a master node, if so, the validity of the transaction request is verified, if the transaction request is legal, the transaction request is stored to a preset storage path, if the transaction request is illegal, the transaction request is deleted, and if not, the transaction request is forwarded, thereby providing a basis for subsequently improving block output efficiency.
Fig. 4 is a schematic flow chart of a block chain consensus method according to a fourth embodiment of the present invention, where on the basis of any of the foregoing embodiments, as shown in fig. 4, the method further includes:
step 401, receiving a consensus request initiated by a master node, wherein the consensus request is broadcasted to a block chain after the master node signs a signature through a private key of the master node, and each master node continuously produces a preset number of blocks;
step 402, verifying the consensus request through a pre-stored public key of the master node, and sending verification information according to a verification result, wherein the verification information comprises confirmation information and suspicion information;
step 403, if the number of the confirmation information is detected to exceed a preset threshold value, generating a new block according to the consensus request;
step 404, if the broadcast information generated by the block is received, deleting the transaction request currently cached.
In this embodiment, a consensus request initiated by a master node is received, the consensus request is verified, and after a block output operation is performed when it is detected that acknowledgement information exceeds a preset threshold, block output information may be broadcasted to a block chain to indicate that a currently output block is successful. Therefore, to further improve the chunking efficiency, other chunks that do not validate the consensus request may delete the currently cached transaction request so that it can validate the next consensus request as soon as possible.
The block chain consensus method provided in this embodiment deletes the transaction request currently cached by receiving the broadcast information generated by the block, thereby effectively increasing the block speed of the block chain.
Fig. 5 is a schematic flow chart of a block chain consensus method according to a fifth embodiment of the present invention, where on the basis of any of the foregoing embodiments, as shown in fig. 5, the method includes:
step 501, receiving a consensus request initiated by the master node according to a block output sequence agreed by each master node in a current block chain, wherein the consensus request is broadcasted to the block chain after the master node signs through a private key of the master node, and each master node continuously produces a preset number of blocks;
step 502, verifying the consensus request through a pre-stored public key of the master node, and sending verification information according to a verification result, wherein the verification information comprises confirmation information and suspicion information;
step 503, if it is detected that the number of the acknowledgement messages exceeds a preset threshold, generating a new block according to the consensus request.
In this embodiment, the network delay often results in low block-out efficiency of the block chain, for example, the acknowledgement time of 0.5 seconds often results in that the next block-out person does not receive the block of the previous block-out person yet, and the next block-out person ignores the previous block if the next block is generated, resulting in a block chain split (two blocks at the same block height). Such as: two nodes with far routing distance on the network, for example, if the network delay of china and the usa is sometimes 300ms, then it is very likely that the witness in the usa will find out its own new block if it does not receive the new block of the witness in china, and then the block of the witness in china will be skipped by the witness in the usa. Therefore, in order to solve the above technical problem, a consensus request initiated by a master node according to the block-out order agreed by each master node in the current block chain may be received. For example, the original random block output sequence may be changed to a block output sequence determined by the uniform negotiation among all the master nodes around the world, so that the master nodes with low network connection delay may output blocks adjacently. Such as: the chinese witness is followed by the korean witness, then followed by the japanese witness, and so on. This may greatly reduce network latency between witnesses. To ensure that everything is done and that no witness is skipped because of network delay, we provide that each witness continues to produce N blocks above a certain minimum threshold, a number less than the maximum number threshold, i.e., each witness is still responsible for the previous block production, but changes from the first 1 produced only to N produced. In the worst case, the last or two of the N blocks may be skipped by the next witness due to network delay or other unexpected reasons, but the first ones of the N blocks will have sufficient time to pass to the next witness. The whole network broadcasting is carried out immediately after each block is produced, and the block producer waits for 0.5 second to produce the next block and receives the confirmation result of other visitors to the previous block. The production of the new block and the receipt of the old block acknowledgement are performed simultaneously. In most cases, the transaction will be confirmed (irreversible) within 1 second. This includes 0.5 seconds of block production and the time required for other witness confirmation. Once the block reaches the irreversible state (2/3 witness confirmation), forking cannot be performed before, ensuring permanent trust of the transaction. In addition, even if most witnesses want to branch the block chain, the block chain can only compete with the main chain at the same speed (0.5 second), and even if only one witness is left in the main chain, the branch chain can never catch up with the main chain, so that the stability of the system is ensured.
In the block chain consensus method provided in this embodiment, the host node receives a consensus request initiated according to the block output sequence agreed by each host node in the current block chain, so that the stability of the block chain can be ensured on the basis of improving the block output efficiency of the block chain.
Fig. 6 is a schematic structural diagram of a block chain consensus device according to a sixth embodiment of the present invention, where as shown in fig. 6, the device includes:
a consensus request receiving module 61, configured to receive a consensus request initiated by a master node, where the consensus request is broadcasted to a block chain after being signed by the master node through a private key of the master node, and each master node continuously produces a preset number of blocks;
the first verification module 62 is configured to verify the consensus request by using a pre-stored public key of the master node, and send verification information according to a verification result, where the verification information includes confirmation information and suspicion information;
a generating module 63, configured to generate a new block according to the consensus request if it is detected that the number of the acknowledgement messages exceeds a preset threshold.
Further, on the basis of any of the above embodiments, the verification module includes:
the verification unit is used for judging the legality of the consensus request through a pre-stored public key of the main node;
the first processing unit is used for broadcasting confirmation information to the block chain according to a verification result if the consensus request is legal;
and the second processing unit is used for broadcasting the doubtful information to the block chain according to the verification result if the consensus request is illegal.
Further, on the basis of any one of the above embodiments, the apparatus further includes:
the system comprises a transaction request receiving module, a block chain sending module and a block processing module, wherein the transaction request receiving module is used for receiving a transaction request sent by an initiator, and the transaction request is broadcasted to the block chain after the initiator signs through a private key of the initiator;
the judging module is used for judging whether the initiator is a main node or not;
the second verification module is used for verifying the validity of the transaction request if the transaction request is legal, storing the transaction request to a preset storage path if the transaction request is legal, and deleting the transaction request if the transaction request is illegal;
and the forwarding module is used for forwarding the transaction request if the transaction request is not received.
Further, on the basis of any one of the above embodiments, the apparatus further includes:
a deleting module for deleting the transaction request currently cached if the broadcast information generated by the block is received,
further, on the basis of any of the above embodiments, the consensus request receiving module includes:
a request receiving unit, configured to receive a consensus request initiated by the master node according to a block-out sequence agreed by each master node in the current block chain.
Fig. 7 is a schematic structural diagram of a blockchain consensus apparatus according to a seventh embodiment of the present invention, where as shown in fig. 7, the blockchain consensus apparatus includes: a memory 71, a processor 72;
a memory 71; a memory 71 for storing instructions executable by the processor 72;
wherein the processor 72 is configured to execute the blockchain consensus method according to any of the above embodiments by the processor 72.
Yet another embodiment of the present invention further provides a computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, the block chain consensus method according to any one of the above embodiments is implemented.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working process of the apparatus described above may refer to the corresponding process in the foregoing method embodiment, and is not described herein again.
Those of ordinary skill in the art will understand that: all or a portion of the steps of implementing the above-described method embodiments may be performed by hardware associated with program instructions. The program may be stored in a computer-readable storage medium. When executed, the program performs steps comprising the method embodiments described above; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.
Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.