CN109660545B - Alliance chain consensus method and computer storage medium - Google Patents
Alliance chain consensus method and computer storage medium Download PDFInfo
- Publication number
- CN109660545B CN109660545B CN201811611199.6A CN201811611199A CN109660545B CN 109660545 B CN109660545 B CN 109660545B CN 201811611199 A CN201811611199 A CN 201811611199A CN 109660545 B CN109660545 B CN 109660545B
- Authority
- CN
- China
- Prior art keywords
- consensus
- node
- white list
- nodes
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Power Engineering (AREA)
- Small-Scale Networks (AREA)
Abstract
The embodiment of the invention provides a alliance chain consensus method and a computer storage medium, which comprises the steps of firstly sending a white list acquisition request to a management node of an alliance chain so as to request the management node to acquire a node white list according to the white list acquisition request; then receiving a node white list returned by the management node, and randomly selecting an identification of the consensus node from the node white list according to a set node selection rule; sending a consensus request of block data to the consensus node according to the identification of the consensus node; and receiving the consensus information returned by the consensus node, judging whether consensus is achieved according to the consensus information, and acquiring consensus result data. And finally judging whether the block data are successfully identified or not according to the acquired identification result data of the first set number by circularly executing the steps of the first set number. By randomly selecting the consensus nodes in multiple rounds, the complexity of communication between the consensus nodes in the consensus process can be controlled, and the influence of malicious nodes on the consensus result can be reduced.
Description
Technical Field
The embodiment of the invention relates to the technical field of computers, in particular to a federation chain consensus method and a computer storage medium.
Background
The blockchain is a novel application mode which utilizes computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. The block chains are divided into three categories, which are: a public chain, a federation chain (also called a federation blockchain, an industry blockchain), and a private chain. Wherein, the public chain aims at all people; federation chains are targeted to a certain group and limited third parties; private chains are directed to individuals.
The nodes of the alliance chain have stronger safety and performance guarantee than the nodes of the public chain, in order to meet the requirements of high throughput and low energy consumption, many alliance chains currently use a Practical Byzantine Fault Tolerance (PBFT) algorithm to achieve consensus, and a new block can be rapidly generated to achieve non-branching second-level consensus. In such a consensus mechanism, all nodes in the federation need to select a master node, and when a new block needs to be generated, the master node is responsible for generating the new block. Once the master node election occurs, normal consensus cannot be achieved during the master node election, the complexity of communication for performing consensus among nodes reaches O (n ^2), and the higher the number of nodes is, the more obvious the consensus efficiency is reduced.
Disclosure of Invention
In view of the above, an object of the present invention is to provide a federation chain consensus method and a computer storage medium, so as to overcome the problem in the prior art that when the number of federation chain links is large, the complexity of messages communicated between consensus nodes is too high, resulting in a decrease in consensus efficiency.
The embodiment of the invention provides a alliance chain consensus method, which comprises the following steps:
sending a white list acquisition request to a management node of a alliance chain so as to request the management node to send a node white list according to the white list acquisition request, wherein the node white list comprises identifications of all nodes capable of carrying out block data consensus in the alliance chain;
receiving the node white list returned by the management node, and randomly selecting an identification of a consensus node from the node white list according to a set node selection rule;
sending a consensus request of block data to the consensus node according to the identification of the consensus node;
receiving consensus information returned by the consensus node, judging whether consensus is achieved for the consensus request according to the consensus information, and acquiring consensus result data, wherein the consensus information comprises a processing result of the consensus request by the consensus node according to a set consensus mechanism;
returning to the step of executing the step of sending the white list acquisition request to the management node of the alliance chain until the consensus result data of a first set number is acquired;
and judging whether the block data are successfully identified according to the first set quantity of the identification result data.
According to another aspect of the embodiments of the present invention, there is also provided a computer storage medium having stored therein:
the instruction is used for sending a white list acquisition request to a management node of a alliance chain so as to request the management node to send a node white list according to the white list acquisition request, wherein the node white list comprises the identification of all nodes which can perform block data consensus in the alliance chain;
the instruction is used for receiving the node white list returned by the management node and randomly selecting the identification of the consensus node from the node white list according to a set node selection rule;
sending a consensus request of block data to the consensus node according to the identification of the consensus node;
the instruction is used for receiving consensus information returned by the consensus node, judging whether consensus is achieved aiming at the consensus request according to the consensus information, and acquiring consensus result data, wherein the consensus information comprises a processing result of the consensus request by the consensus node according to a set consensus mechanism;
an instruction for returning to the step of sending the white list acquisition request to the management node of the alliance chain until acquiring a first set amount of the consensus result data;
and judging whether the block data are successfully identified according to the first set quantity of the identification result data.
As can be seen from the above technical solutions, in the alliance chain consensus scheme of the embodiment of the present invention, when newly generated block data needs to be block uplink sent, a white list acquisition request is first sent to a management node of an alliance chain, so as to request the management node to send a node white list according to the white list acquisition request; then receiving a node white list returned by the management node, and randomly selecting an identification of the consensus node from the node white list according to a set node selection rule; sending a consensus request of block data to the consensus node according to the identification of the consensus node; and receiving the consensus information returned by the consensus node, judging whether consensus is achieved according to the consensus information, and acquiring consensus result data. And finally judging whether the block data are successfully identified or not according to the acquired identification result data of the first set number by circularly executing the steps of the first set number. Therefore, when the number of all nodes capable of carrying out block data consensus in a alliance chain is too large, the consensus request can be sent to only the randomly selected part of nodes capable of carrying out block data consensus, and the complexity of communication among the nodes in the consensus process is controlled; and random selection of the consensus nodes and consensus request sending can be carried out through multiple rounds, and finally whether consensus on the block data is successful or not is judged according to the consensus result data obtained through multiple rounds so as to reduce the influence of malicious nodes on the consensus result.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the embodiments of the present invention, and for those skilled in the art, other drawings may be obtained according to these drawings.
Fig. 1 shows a flowchart of a federation chain consensus method according to a first embodiment of the present invention.
Fig. 2 shows a flowchart of a federation chain consensus method according to a second embodiment of the present invention.
Detailed Description
In order to make those skilled in the art better understand the technical solutions in the embodiments of the present invention, the technical solutions in the embodiments of the present invention will be described clearly and completely with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments of the present invention should fall within the scope of the protection of the embodiments of the present invention.
The following further describes specific implementation of the embodiments of the present invention with reference to the drawings.
Example one
Fig. 1 shows a flowchart of a federation chain consensus method according to a first embodiment of the present invention. Referring to fig. 1, a federation chain consensus method of an embodiment of the present invention includes the following steps:
step S101: and sending a white list acquisition request to a management node of the alliance chain so as to request the management node to send a node white list according to the white list acquisition request, wherein the node white list comprises the identification of all nodes capable of carrying out block data consensus in the alliance chain.
In this embodiment, since the federation chain is for a certain specific group and limited third parties, and an admission mechanism exists, a manager of the federation chain can manage admission, consensus authority, block export authority, and the like of all nodes of the federation chain through at least one management node, so that a node range in the federation chain, where block data consensus can be performed, and a node range where block data can be generated and block export uplink can be performed, can be queried or obtained from the management node. For example, when a node joins a federation chain, it needs to first provision a federation chain manager, that is, it needs to submit a registration procedure, and after the administrator passes the audit, the node will register as a federation chain node in the management node, and set a relevant authority, thereby joining the federation chain.
In this embodiment, in the alliance chain, only after the node capable of performing block data consensus successfully performs block data consensus on the block data, the requesting node may perform block uplink on the newly generated block data, and therefore, when the requesting node needs to perform block uplink on the newly generated block data, the requesting node may first send a white list acquisition request to the management node to request to acquire a white list of nodes capable of performing block data consensus in the alliance chain from the management node, and then initiate a block data consensus request to all or part of the nodes in the white list of nodes to perform consensus on the block data.
Optionally, the node white list is used to determine a range of all nodes capable of block data consensus currently in the federation chain, and may include an identifier of all nodes capable of block data consensus in the federation chain. Because the nodes in the federation chain can be dynamically added or withdrawn, and the range of the nodes which can perform block data consensus at different time points may change, the management node updates the node white list in real time according to the adding or withdrawing condition of the nodes in the federation chain.
Step S102: and receiving a node white list returned by the management node, and randomly selecting the identification of the consensus node from the node white list according to a set node selection rule.
In this embodiment, when the number of all nodes capable of performing block data consensus in the federation chain is too large, if a consensus request for sending block data to all nodes capable of performing block data consensus may cause a problem of high inter-node communication complexity, which affects consensus efficiency, therefore, only a part of nodes capable of performing block data consensus may be selected from a node white list as consensus nodes according to a set node selection rule, and in a subsequent step, the consensus request for block data is processed only by the consensus nodes, so as to reduce inter-node communication complexity.
Optionally, the node selection rule is at least used to determine the number of the consensus nodes, so as to control the communication complexity between the consensus nodes when processing the consensus requests of the block data in the subsequent step. In practical application, the node selection rule is not limited, and can be set according to factors such as engineering implementation requirements, network environment, hardware performance and the like.
In this embodiment, in order to prevent malicious nodes from prejudging the sampling result and thus launch DDOS attack to cause consensus failure, a random sampling algorithm may be adopted to randomly select the identity of the consensus node from a node white list. The random sampling algorithm is not limited in kind, and can be set according to requirements in practical application.
Optionally, in order to ensure reliability of communication, the random sampling algorithm needs to be deployed in advance to each request node and a node capable of performing block data consensus, so that after receiving a consensus request in a subsequent step, the consensus node can determine whether the consensus node is a node selected according to the random sampling algorithm, so as to perform authenticity check on the consensus request.
Step S103: and sending a consensus request of the block data to the consensus node according to the identification of the consensus node.
In this embodiment, the node white list may further include address information of all nodes capable of performing block data consensus, so that after the consensus node is selected, the consensus request of the block data may be sent to the consensus node according to the address information of the consensus node. For example, if the management node allocates the address information corresponding to each node in the federation chain as the identifier of the node, the address information corresponding to the consensus node can be obtained directly by reading the identifier of the consensus node.
In this embodiment, the consensus request is used to request the consensus node to perform the consensus process according to the set consensus mechanism, where the information and format included in the consensus request are not limited, and may be set according to the consensus mechanism selected by the federation chain in practical applications.
Step S104: and receiving consensus information returned by the consensus node, judging whether consensus is achieved for the consensus request according to the consensus information, and acquiring consensus result data, wherein the consensus information comprises a processing result of the consensus request by the consensus node according to a set consensus mechanism.
In this embodiment, in practical application, each consensus node may process the received consensus request according to a consensus mechanism and return consensus information, so that it is determined whether all the consensus nodes achieve consensus on the consensus requests sent in the current round according to the consensus information returned by all the consensus nodes, and consensus result data is obtained. The consensus result data is at least used for recording the consensus requests sent for the current round, and all the consensus nodes achieve consensus or do not achieve consensus.
Step S105: and returning to execute the step of sending the white list acquisition request to the management node of the alliance chain until the first set quantity of consensus result data is acquired.
In this embodiment, since the consensus result data is only data obtained by processing the consensus request according to the consensus node, the consensus node may only be a part of the nodes capable of performing block data consensus, and if all or most of the consensus nodes belong to the malicious nodes, the consensus may fail, so that to reduce the influence of the malicious nodes on the success rate of consensus, the multiple rounds of random selection of the consensus nodes and sending of the consensus request may be performed, that is, the first set number is greater than or equal to 2, so that the ranges of the nodes capable of performing block data consensus, which are processed by different rounds of consensus requests according to the set consensus mechanism, are different, and it is finally determined whether the block data are successfully agreed according to the multiple rounds of obtained consensus result data.
Specifically, the number of rounds of randomly selecting the consensus node and sending the consensus request can be set according to the first set number, so as to obtain the consensus result data of the first set number. From the perspective of probability theory, the larger the first set number is, the lower the probability of failure of consensus caused by a malicious node is, but the time consumed by the whole consensus process of the block data is increased, so that the first set number can be set according to factors such as engineering implementation requirements, network environment, hardware performance and the like in practical application.
In this embodiment, since the white list of the nodes in the management node may change over time, that is, the range of the nodes currently capable of performing block data consensus may change, in order to reduce the probability of selecting the same consensus node range as that of the previous round when step S103 is executed again, when the number of times of obtaining consensus result data in the overall consensus process of the block data does not reach the first set number, after obtaining the consensus result data once, step S101 may be returned to, so as to request the management node to obtain the latest white list of the nodes again.
Step S106: and judging whether the block data are successfully identified according to the first set quantity of the identification result data.
In this embodiment, in practical application, a consensus result determination rule may be first set according to engineering requirements or application scenarios, so that after a first set number of consensus result data are obtained, whether the block data are successfully consensus can be determined by using the consensus result determination rule.
For example, the consensus judgment rule may be set to "if the consensus is successful if more than or equal to 60% of the consensus result data is recorded", and if 10 times of the consensus result data are obtained in the entire consensus process for the block data, wherein the consensus is recorded in 8 times of the obtained consensus result data, the consensus is not recorded in 2 times of the obtained consensus result data, and the proportion of the consensus is 80% or more than 60%, the block data can be determined to be successful according to the consensus judgment rule.
As can be seen from the above embodiments of the present invention, when a requesting node needs to perform block uplink on newly generated block data, a white list acquisition request is first sent to a management node of a federation chain to request the management node to send a node white list according to the white list acquisition request; then receiving a node white list returned by the management node, and randomly selecting an identification of the consensus node from the node white list according to a set node selection rule; sending a consensus request of block data to the consensus node according to the identification of the consensus node; and receiving the consensus information returned by the consensus node, judging whether consensus is achieved according to the consensus information, and acquiring consensus result data. And finally judging whether the block data are successfully identified or not according to the acquired identification result data of the first set number by circularly executing the steps of the first set number. Therefore, when the number of all nodes capable of carrying out block data consensus in a alliance chain is too large, the consensus request can be sent to only the randomly selected part of nodes capable of carrying out block data consensus, and the complexity of communication among the nodes in the consensus process is controlled; and random selection of the consensus nodes and consensus request sending can be carried out through multiple rounds, and finally whether consensus on the block data is successful or not is judged according to the consensus result data obtained through multiple rounds so as to reduce the influence of malicious nodes on the consensus result.
Example two
Fig. 2 shows a flowchart of a federation chain consensus method according to a second embodiment of the present invention. As shown in fig. 2, the federation chain consensus method of the embodiment of the present invention includes the following steps:
step S201: and sending a white list acquisition request to a management node of the alliance chain so as to request the management node to carry out identity verification on the request node according to the white list acquisition request, and if the verification is passed, sending a node white list to the request node.
In this embodiment, in order to ensure communication security and avoid leakage of related information of the alliance link node, the management node may perform identity verification on the request node first after receiving the white list acquisition request sent by the request node, and may send the node white list to the request node only after the verification passes.
Optionally, the management node may allocate an identifier to each node in the federation chain according to a set identifier rule, so as to distinguish different nodes, and store identifiers of all nodes capable of performing block data consensus in the federation chain into a node white list.
Optionally, the management node may obtain the request by analyzing the white list, and obtain information for identifying the request node, so as to perform identity authentication on the request node according to the information for identifying the request node. For example, the authentication may include determining whether the requesting node belongs to an admitted node or whether the requesting node belongs to a node that can generate block data and perform block uplink.
Optionally, for the nodes admitted to the management node in the federation chain, at least the address information of the node is recorded in the management node, for example, I P addresses and ports of all nodes in the federation chain can be recorded in the management node. In order to reduce the data storage amount, the management node can allocate address information corresponding to each node in the federation chain as the identifier of the node. Correspondingly, the white list acquisition request may include address information of the request node, and after receiving the white list acquisition request, the management node may perform identity verification on the request node according to the address information of the request node acquired by analyzing the white list acquisition request.
Optionally, in order to reduce the complexity of the node permissions of the alliance chain system, the node ranges having the common permission and the block output permission may be set to be the same node range, that is, all the nodes capable of performing block data common identification in the alliance chain may generate block data and perform block output uplink, and all the nodes capable of generating block data and performing block output uplink may also perform block data common identification. Thus, if the requesting node has the block-out authority, it also has a consensus authority, i.e., the requesting node's identity is included in the node white list. Correspondingly, step S201 may include:
and sending a white list acquisition request to a management node of the alliance chain so as to request the management node to analyze the white list acquisition request, acquire the identifier of the request node, judge whether the identifier of the request node is in the node white list or not, and if so, sending the node white list to the request node.
Optionally, in order to improve the decentralized degree of the federation chain and reduce the data processing amount of the management node, the management node may not participate in the subsequent step, that is, the node white list does not include the identifier of the management node.
Step S202: and receiving a node white list returned by the management node, and randomly selecting the identification of the consensus node from the node white list according to a set node selection rule.
In this embodiment, when the number of all nodes capable of performing block data consensus in the federation chain is small, if multiple rounds of consensus node selection are still performed, a phenomenon that ranges of consensus nodes selected in different rounds are completely overlapped may occur, so that consensus result data obtained multiple times in subsequent steps are completely the same, that is, the same batch of consensus nodes repeatedly perform consensus processing on the same consensus request, and the consensus efficiency is reduced instead. Therefore, to avoid the foregoing phenomenon, step S202 may include sub-steps S202 a-S202 c:
sub-step S202 a: and determining the total quantity of all nodes capable of carrying out block data consensus in the alliance chain according to the node white list, and judging whether the total quantity of the nodes is greater than a second set quantity.
Specifically, since theoretically, the greater the number of consensus nodes participating in processing the consensus request per round is, the lower the possibility that the malicious node affects the consensus result is, but the communication traffic between the nodes is increased greatly, the upper limit of the number of consensus nodes randomly selected per round can be determined by the second set number, and the number of rounds of randomly selecting the consensus nodes and sending the consensus requests can be further determined according to the second set number.
Optionally, in order to select the consensus nodes as many as possible on the premise of ensuring the overall operation efficiency of the alliance chain, the second set number may be determined according to the network environment and/or the hardware performance of all nodes capable of performing block data consensus in the alliance chain.
Optionally, the total number of nodes may be obtained by analyzing the number of identifiers of nodes in the node white list, which may perform block data consensus; or judging whether the node white list comprises the node total amount counted and recorded by the management node, and if so, directly reading the node total amount from the white list.
Sub-step S202 b: and if so, randomly selecting a second set number of identifiers from the node white list as the identifiers of the common identification nodes.
Specifically, when the total number of nodes is greater than the second set number, it indicates that at least two different consensus node ranges can be selected for performing at least two rounds of consensus request processing on the block data.
Optionally, since the integer number of the value obtained by dividing the total number of the nodes by the second set number is used, it is possible to determine how many completely different consensus node ranges can be selected, that is, if the consensus node ranges required to perform consensus request processing in each round are completely different, how many groups of the nodes capable of performing block data consensus can be divided in the federation chain. Therefore, in order to allow the nodes in the federation chain capable of performing block data consensus to participate in at least one round of block data consensus request processing, a first set number may be determined according to the total number of nodes and a second set number, where a value of the first set number is greater than or equal to a value obtained by dividing the total number of nodes by the second set number.
Sub-step S202 c: if not, all the identifiers in the node white list are selected as the identifiers of the common identification nodes, and the first set number is adjusted to be 1.
Specifically, when the total number of the nodes is less than the second set number, it indicates that the consensus nodes of the second set number cannot be selected; when the total number of the nodes is equal to a second set number, the common node selected each time is exactly the node which can perform block data common identification in the alliance chain. Therefore, under the above situation, it is not necessary to perform multiple rounds of random selection of the consensus node and send the consensus request, and all the nodes capable of performing block data consensus in the federation chain perform a round of processing of the consensus request. In addition, since the first set number is used to set the number of rounds of randomly selecting and sending the consensus node, the first set number needs to be adjusted to 1.
In this embodiment, when the total number of all nodes capable of performing block data consensus in the federation chain is greater than the second set number, if a random algorithm is used in each round to select consensus nodes from all nodes capable of performing block data consensus, the closer the total number of nodes is to the second set number, the higher the probability that the ranges of the consensus nodes selected in the two rounds are completely the same. Therefore, at least in order to avoid the same range of the consensus nodes obtained in two consecutive rounds of selection, when the total number of the nodes is greater than or equal to twice of the second set number, the selected consensus nodes can be marked, that is, the selected labels are added to the identifications of the consensus nodes.
Correspondingly, the step S202 may further include sub-steps S202 d-S202 e:
sub-step S202 d: and screening the identifiers of the nodes in the node white list according to the selected tags to obtain the identifiers of the nodes without the selected tags.
Sub-step S202 e: and randomly selecting the identification of the consensus node from the identifications of the nodes without the selected labels.
Step S203: and sending a consensus request of the block data to the consensus node according to the identification of the consensus node.
Step S204: and receiving consensus information returned by the consensus node, judging whether consensus is achieved for the consensus request or not according to the consensus information, and acquiring consensus result data, wherein the consensus information comprises a processing result of the consensus request by the consensus node according to a set consensus mechanism.
Step S205: and returning to execute the step of sending the white list acquisition request to the management node of the alliance chain until the first set quantity of consensus result data is acquired.
Step S206: determining the number of times of achieving consensus according to the consensus result data of the first set number; and judging whether the number of times of reaching the consensus is larger than or equal to a third set number, if so, the consensus is successful.
In this embodiment, the third predetermined number is used to limit the lowest value of the number of times of reaching the consensus. In order to ensure the consensus security, the consensus mechanism selected by the alliance chain can be used for determining the lowest value of the normal node ratio allowed by the fault-tolerant security of the consensus mechanism, and then determining a third set number according to the lowest value of the allowed normal node ratio, wherein the value obtained by dividing the third set number by the first set number is greater than or equal to the lowest value of the allowed normal node ratio.
Optionally, the set consensus mechanism is a practical byzantine fault-tolerant algorithm, and since the consensus request is initiated by the request node in this embodiment, the election of the master node is not needed, so that a situation that the practical byzantine fault-tolerant algorithm cannot realize normal consensus during the election period is avoided.
Furthermore, since at least 4 consensus nodes are required for the proper operation of the applicable byzantine fault-tolerant algorithm, and the fault-tolerant security allows the total malicious node proportion on the federation chain to be less than 1/3, i.e. the normal node proportion is greater than or equal to 2/3, it is correspondingly possible to set the second set number to be greater than or equal to 4 and the value of the third set number divided by the first set number to be greater than or equal to 2/3.
Step S207: and if the consensus is successful, uplink the block data in the alliance chain and broadcast the data information of the block data in the whole network.
In this embodiment, if the consensus is successful, the requesting node may uplink the corresponding block data in the alliance chain and broadcast the data information of the block data to all nodes in the alliance chain, wherein the management node may allocate the corresponding identifier to the block data to ensure data consistency.
It can be seen from the above embodiments of the present invention that, in the present invention, the management node can obtain the request according to the white list to perform the identity verification of the requesting node, and if the verification is passed, the management node sends the node white list to the requesting node, which can ensure the communication safety and avoid the leakage of the related information of the alliance link node; the upper limit of the number of the consensus nodes randomly selected in each round can be limited by setting a second set number so as to control the communication complexity between the consensus nodes for performing consensus processing on the consensus requests in each round; determining the first set quantity according to the second set quantity, so that the consensus of the block data can be efficiently completed no matter how many nodes can perform the consensus of the block data in the alliance chain; by adding the selected label to the identification of the consensus node, the situation that the consensus node ranges from two consecutive rounds of selection are the same can be avoided, and the influence of malicious nodes on the success of consensus can be weakened.
EXAMPLE III
The embodiment of the invention also provides a computer storage medium, wherein the computer storage medium stores:
the management node is used for sending a white list acquisition request to the management node of the alliance chain so as to request the management node to send a white list of the node according to the white list acquisition request, wherein the white list of the node comprises the identification of all nodes which can perform block data consensus in the alliance chain;
the instruction is used for receiving the node white list returned by the management node and randomly selecting the identification of the consensus node from the node white list according to the set node selection rule;
sending a consensus request of the block data to the consensus node according to the identification of the consensus node;
the instruction is used for receiving the consensus information returned by the consensus node, judging whether consensus is achieved aiming at the consensus request according to the consensus information, and acquiring consensus result data, wherein the consensus information comprises a processing result of the consensus request by the consensus node according to a set consensus mechanism;
the step of sending the white list acquisition request to the management node of the alliance chain is executed in a return mode until the first set number of consensus result data are acquired;
and instructions for determining whether the block data are successfully identified according to the first set number of the identification result data.
Optionally, the method further includes: and the management node is used for sending a white list acquisition request to the management node of the alliance chain so as to request the management node to carry out identity authentication on the request node according to the white list acquisition request, and if the authentication is passed, sending a node white list instruction to the request node.
Optionally, the method further includes: instructions for determining the total amount of all nodes capable of performing block data consensus in the alliance chain according to the node white list, and judging whether the total amount of the nodes is larger than a second set amount;
an instruction for randomly selecting a second set number of identifiers from the node white list as identifiers of the consensus nodes if the node white list is the same as the consensus node;
and if not, selecting all the identifiers in the node white list as identifiers of the common identification nodes, and adjusting the first set number to be 1.
Optionally, the method further includes: and determining a second set number of instructions according to the network environment and/or hardware performance of all nodes which can perform block data consensus in the alliance chain.
Optionally, the method further includes: and determining a first set number instruction according to the total number of the nodes and a second set number, wherein the value of the first set number is larger than or equal to the value of the total number of the nodes divided by the second set number.
Optionally, the method further includes: and instructions for determining the number of times of reaching the consensus according to the consensus result data of the first set number, judging whether the number of times of reaching the consensus is larger than or equal to a third set number, and if so, the consensus is successful.
Optionally, the set consensus mechanism is a practical byzantine fault-tolerant algorithm, and correspondingly, the second set number is greater than or equal to 4, and a value obtained by dividing the third set number by the first set number is greater than or equal to 2/3.
Optionally, the method further includes: the instruction is used for screening the identifiers of the nodes in the node white list according to the selected tags to obtain the identifiers of the nodes without the selected tags;
and instructions for randomly selecting the identification of the consensus node from the identifications of the nodes to which the selected label is not added.
Optionally, the identifier of the management node is not included in the node white list.
Through the computer storage medium of this embodiment, the corresponding federation chain consensus method in the foregoing method embodiments can be implemented, and has the beneficial effects of the corresponding method embodiments, which are not described herein again.
It should be noted that, according to the implementation requirement, each component/step described in the embodiment of the present invention may be divided into more components/steps, and two or more components/steps or partial operations of the components/steps may also be combined into a new component/step to achieve the purpose of the embodiment of the present invention.
The above-described method according to an embodiment of the present invention may be implemented in hardware, firmware, or as software or computer code storable in a recording medium such as a CD ROM, a RAM, a floppy disk, a hard disk, or a magneto-optical disk, or as computer code originally stored in a remote recording medium or a non-transitory machine-readable medium downloaded through a network and to be stored in a local recording medium, so that the method described herein may be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware such as an ASIC or FPGA. It will be appreciated that a computer, processor, microprocessor controller, or programmable hardware includes a storage component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code that, when accessed and executed by a computer, processor, or hardware, implements the federation chain consensus method described herein. Further, when a general-purpose computer accesses code for implementing the federation chain consensus method illustrated herein, execution of the code transforms the general-purpose computer into a special-purpose computer for performing the federation chain consensus method illustrated herein.
Those of ordinary skill in the art will appreciate that the various illustrative elements and method steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present embodiments.
The above embodiments are only for illustrating the embodiments of the present invention and not for limiting the embodiments of the present invention, and those skilled in the art can make various changes and modifications without departing from the spirit and scope of the embodiments of the present invention, so that all equivalent technical solutions also belong to the scope of the embodiments of the present invention, and the scope of patent protection of the embodiments of the present invention should be defined by the claims.
Claims (8)
1. A federation chain consensus method, comprising:
sending a white list acquisition request to a management node of a alliance chain so as to request the management node to send a node white list according to the white list acquisition request, wherein the node white list comprises identifications of all nodes capable of carrying out block data consensus in the alliance chain;
receiving the node white list returned by the management node, and randomly selecting an identification of a consensus node from the node white list according to a set node selection rule;
sending a consensus request of block data to the consensus node according to the identification of the consensus node;
receiving consensus information returned by the consensus node, judging whether consensus is achieved for the consensus request according to the consensus information, and acquiring consensus result data, wherein the consensus information comprises a processing result of the consensus request by the consensus node according to a set consensus mechanism;
returning to the step of executing the step of sending the white list acquisition request to the management node of the alliance chain until the consensus result data of a first set number is acquired;
judging whether the block data are successfully identified according to the first set quantity of the identification result data;
wherein, the determining whether the block data is successfully identified according to the first set number of the consensus result data comprises: determining the number of times of achieving consensus according to the consensus result data of the first set number; judging whether the number of times of reaching the consensus is larger than or equal to a third set number, if so, the consensus is successful;
wherein the method further comprises: adding a selected label to the identification of the consensus node; correspondingly, the randomly selecting the identification of the consensus node from the node white list according to the set node selection rule includes:
screening the identifiers of the nodes in the node white list according to the selected tags to obtain the identifiers of the nodes without the selected tags;
and randomly selecting the identification of the common node from the identifications of the nodes without the selected labels.
2. The method of claim 1, wherein sending a white list acquisition request to a management node of a federation chain requesting the management node to send a node white list according to the white list acquisition request comprises:
and sending the white list acquisition request to the management node of the alliance chain to request the management node to carry out identity authentication of the request node according to the white list acquisition request, and if the authentication is passed, sending a node white list to the request node.
3. The method of claim 1, wherein the randomly selecting the identity of the consensus node from the node white list according to the set node selection rule comprises:
determining the total amount of all nodes capable of carrying out block data consensus in a alliance chain according to the node white list, and judging whether the total amount of the nodes is larger than a second set amount;
if yes, randomly selecting a second set number of identifiers from the node white list as identifiers of the consensus nodes;
if not, all the identifiers in the node white list are selected as the identifiers of the common identification nodes, and the first set number is adjusted to be 1.
4. The method of claim 3, further comprising:
and determining the second set number according to the network environment and/or hardware performance of all nodes which can perform block data consensus in the alliance chain.
5. The method of claim 3, further comprising:
and determining the first set number according to the total number of the nodes and the second set number, wherein the value of the first set number is greater than or equal to the value of dividing the total number of the nodes by the second set number.
6. The method of claim 3, wherein the set consensus mechanism is a practical Byzantine fault tolerance algorithm, and wherein the second set number is greater than or equal to 4 and the third set number divided by the first set number is greater than or equal to 2/3.
7. The method of claim 1, wherein the node white list does not include an identification of the management node.
8. A computer storage medium, comprising stored therein:
the instruction is used for sending a white list acquisition request to a management node of a alliance chain so as to request the management node to send a node white list according to the white list acquisition request, wherein the node white list comprises the identification of all nodes which can perform block data consensus in the alliance chain;
the instruction is used for receiving the node white list returned by the management node and randomly selecting the identification of the consensus node from the node white list according to a set node selection rule;
sending a consensus request of block data to the consensus node according to the identification of the consensus node;
the instruction is used for receiving consensus information returned by the consensus node, judging whether consensus is achieved aiming at the consensus request according to the consensus information, and acquiring consensus result data, wherein the consensus information comprises a processing result of the consensus request by the consensus node according to a set consensus mechanism;
an instruction for returning to the step of sending the white list acquisition request to the management node of the alliance chain until acquiring a first set amount of the consensus result data;
instructions for determining whether the block data are successfully identified according to the first set amount of the consensus result data;
the instruction for judging whether the block data is successfully identified according to the first set number of the identification result data comprises an instruction for determining the number of times of achieving the identification according to the first set number of the identification result data, judging whether the number of times of achieving the identification is greater than or equal to a third set number, and if so, successfully identifying;
the computer storage medium further having stored therein: adding an instruction of a selected label to the identification of the consensus node;
the instruction for randomly selecting the identification of the consensus node from the node white list according to the set node selection rule comprises:
the instruction is used for screening the identifiers of the nodes in the node white list according to the selected tags to obtain the identifiers of the nodes without the selected tags;
and instructions for randomly selecting the identification of the consensus node from the identifications of the nodes to which the selected label is not added.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811611199.6A CN109660545B (en) | 2018-12-27 | 2018-12-27 | Alliance chain consensus method and computer storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811611199.6A CN109660545B (en) | 2018-12-27 | 2018-12-27 | Alliance chain consensus method and computer storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109660545A CN109660545A (en) | 2019-04-19 |
| CN109660545B true CN109660545B (en) | 2021-04-09 |
Family
ID=66117396
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811611199.6A Active CN109660545B (en) | 2018-12-27 | 2018-12-27 | Alliance chain consensus method and computer storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109660545B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110300171B (en) * | 2019-06-28 | 2022-04-15 | 深圳市元征科技股份有限公司 | Information acquisition method, system, computer readable storage medium and electronic device |
| CN110460634B (en) * | 2019-07-02 | 2020-10-27 | 特斯联（北京）科技有限公司 | Edge computing consensus request management method and system |
| CN112600698B (en) * | 2020-12-07 | 2023-06-13 | 合肥达朴汇联科技有限公司 | Block chain consensus method, system, equipment and medium applied to non-block-out node |
| CN112583908B (en) * | 2020-12-07 | 2024-04-16 | 合肥达朴汇联科技有限公司 | Block chain consensus method, system, equipment and medium applied to block outlet node |
| CN113486118B (en) * | 2021-07-21 | 2023-09-22 | 银清科技有限公司 | Consensus node selection method and device |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106878000A (en) * | 2017-03-06 | 2017-06-20 | 中钞信用卡产业发展有限公司北京智能卡技术研究院 | A kind of alliance's chain common recognition method and system |
| CN108197959A (en) * | 2018-01-23 | 2018-06-22 | 华南理工大学 | A kind of fast verification pond based on block chain, fast verification system and operating method |
| CN108769163A (en) * | 2018-05-16 | 2018-11-06 | 深圳前海微众银行股份有限公司 | Alliance's chain common recognition reaches method, equipment and computer readable storage medium |
| CN108881169A (en) * | 2018-05-21 | 2018-11-23 | 西安电子科技大学 | Time distribution and synchronous method and system, data processing system based on block chain |
| CN109040012A (en) * | 2018-06-19 | 2018-12-18 | 西安电子科技大学 | A kind of data security protecting and sharing method based on block chain and system and application |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0586768A1 (en) * | 1992-09-11 | 1994-03-16 | International Business Machines Corporation | Efficient multi-users timer |
| US20110066857A1 (en) * | 2001-06-22 | 2011-03-17 | Probst David K | Method for secure delivery of digital content |
| US10075298B2 (en) * | 2015-06-02 | 2018-09-11 | ALTR Solutions, Inc. | Generation of hash values within a blockchain |
| US10121019B2 (en) * | 2015-06-02 | 2018-11-06 | ALTR Solutions, Inc. | Storing differentials of files in a distributed blockchain |
| CN107018125B (en) * | 2017-02-17 | 2019-08-09 | 阿里巴巴集团控股有限公司 | A kind of block catenary system, date storage method and device |
| CN107391320B (en) * | 2017-03-10 | 2020-07-10 | 创新先进技术有限公司 | Consensus method and device |
| CN107360206B (en) * | 2017-03-29 | 2020-03-27 | 创新先进技术有限公司 | Block chain consensus method, equipment and system |
| CN107612973B (en) * | 2017-08-18 | 2020-12-11 | 暨南大学 | Block chain structure for intelligent mobile terminal, generation method and transaction verification method |
| CN108632362B (en) * | 2018-04-12 | 2021-04-06 | 北京天德科技有限公司 | Method for electing private block chain building block node |
| CN108596623B (en) * | 2018-05-09 | 2021-02-02 | 合肥达朴汇联科技有限公司 | Block chain consensus achieving method |
| CN108665274A (en) * | 2018-05-14 | 2018-10-16 | 北京链享未来科技有限公司 | A kind of accounting nodes intelligent selecting method |
-
2018
- 2018-12-27 CN CN201811611199.6A patent/CN109660545B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106878000A (en) * | 2017-03-06 | 2017-06-20 | 中钞信用卡产业发展有限公司北京智能卡技术研究院 | A kind of alliance's chain common recognition method and system |
| CN108197959A (en) * | 2018-01-23 | 2018-06-22 | 华南理工大学 | A kind of fast verification pond based on block chain, fast verification system and operating method |
| CN108769163A (en) * | 2018-05-16 | 2018-11-06 | 深圳前海微众银行股份有限公司 | Alliance's chain common recognition reaches method, equipment and computer readable storage medium |
| CN108881169A (en) * | 2018-05-21 | 2018-11-23 | 西安电子科技大学 | Time distribution and synchronous method and system, data processing system based on block chain |
| CN109040012A (en) * | 2018-06-19 | 2018-12-18 | 西安电子科技大学 | A kind of data security protecting and sharing method based on block chain and system and application |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109660545A (en) | 2019-04-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109660545B (en) | Alliance chain consensus method and computer storage medium | |
| CN110784346B (en) | Reputation value-based PBFT consensus system and method | |
| CN107171810B (en) | Verification method and device of block chain | |
| CN112311735B (en) | Credible authentication method, network equipment, system and storage medium | |
| CN111383021B (en) | Node management method, device, equipment and medium based on block chain network | |
| CN109688186B (en) | Data interaction method, device, equipment and readable storage medium | |
| CN109698753B (en) | Block chain-based uplink consensus algorithm matching method and device | |
| CN109379343B (en) | Heterogeneous consensus method of block chains and terminal | |
| CN112527912B (en) | Data processing method and device based on block chain network and computer equipment | |
| CN110086780B (en) | Method and device for processing tampered transaction based on Ether house and storage medium | |
| CN112202753A (en) | Data stream detection method and system based on cloud platform and block chain | |
| CN113328997A (en) | Alliance chain cross-chain system and method | |
| CN112749968B (en) | Service data recording method and device based on block chain | |
| CN110839002B (en) | Cloud account opening, authentication and access method and device | |
| CN110324331A (en) | Power system security stability contorting terminal identity authentication method based on block chain | |
| CN111585995B (en) | Secure wind control information transmission and processing method and device, computer equipment and storage medium | |
| CN113055176A (en) | Terminal authentication method and system, terminal device, P2P verification platform and medium | |
| CN113626875A (en) | Knowledge graph file storage method for block chain fragment enabling | |
| CN113904854B (en) | Block chain data encryption method and device based on quotient algorithm | |
| CN109274674B (en) | Block chain heterogeneous consensus method with high security and terminal | |
| CN109299053B (en) | File operation method, device and computer storage medium | |
| CN115396443A (en) | Time factor-based alliance chain consensus method, device, equipment and storage medium | |
| CN113824738A (en) | Method and system for node communication management in block chain | |
| CN111563740A (en) | Transaction processing method and system of alliance chain | |
| CN113032089B (en) | Distributed simulation service construction method based on API gateway |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |