CN110569395A - stable and reliable block chain Byzantine consensus process design method - Google Patents
stable and reliable block chain Byzantine consensus process design method Download PDFInfo
- Publication number
- CN110569395A CN110569395A CN201810481158.3A CN201810481158A CN110569395A CN 110569395 A CN110569395 A CN 110569395A CN 201810481158 A CN201810481158 A CN 201810481158A CN 110569395 A CN110569395 A CN 110569395A
- Authority
- CN
- China
- Prior art keywords
- data
- consensus
- node
- processing
- height
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 64
- 238000013461 design Methods 0.000 title claims abstract description 16
- 238000012545 processing Methods 0.000 claims abstract description 39
- 238000004891 communication Methods 0.000 claims abstract description 12
- 230000005856 abnormality Effects 0.000 claims abstract description 7
- 238000004364 calculation method Methods 0.000 claims description 9
- 230000002159 abnormal effect Effects 0.000 claims description 3
- 238000005516 engineering process Methods 0.000 abstract description 3
- 238000005457 optimization Methods 0.000 abstract description 2
- 238000013507 mapping Methods 0.000 description 9
- 238000012795 verification Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 2
- 238000012216 screening Methods 0.000 description 2
- 206010033799 Paralysis Diseases 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000004886 process control Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
Abstract
the invention relates to a block chain bottom layer technology, in particular to a stable and reliable block chain Byzantine consensus process design method, which is characterized by comprising the following points: (1) when the system waits for collecting data sent by other nodes, including but not limited to transaction data, block data, voting data and the like, setting timeout time, and entering an timeout processing flow after the timeout; (2) the overtime processing distinguishes processing within the fault tolerance range from processing outside the fault tolerance range according to the collected data; (3) the communication data in the consensus process carries height information corresponding to the data, the height is screened when the data are received, the data which do not meet the height requirement do not enter consensus, different communication data have different cache pools, and the height is used as a key for storage; (4) any abnormality in the system is properly processed, and the consensus process cannot be influenced. The invention designs a block chain consensus process optimization method, so that an original complex and efficient block chain consensus system is stable and reliable.
Description
Technical Field
the invention relates to an optimization design of a block chain bottom layer consensus process, in particular to a stable and reliable block chain Byzantine consensus process design method.
Background
the block chain technology is continuously applied to promote development, and the requirement of application on the block chain is higher and higher from establishing a bitcoin of one block in tens of minutes to establishing a novel block chain of one block in 1 second at present. The consensus system of the blockchain appears to be extremely unstable and reliable in such harsh environments.
in the conventional block chain system implemented based on the consensus algorithm, the consensus step includes the following steps:
(1) Each node creates a transaction map and broadcasts the transaction map;
(2) After all the transaction mapping graphs of all the nodes are collected by each node, a public transaction intersection is obtained through operation;
(3) The building node builds a block and broadcasts the block;
(4) After receiving the block, the non-block building node carries out verification and voting, and meanwhile, broadcasts the voting result;
(5) and each node collects the voting information forwarded by all the nodes, and calculates a final voting result (success or failure) according to a Byzantine consensus algorithm.
although the above steps implement the consensus process of the distributed blockchain system, the stability is poor, various problems may occur in the actual network environment, and the consensus process of the blockchain may be aborted due to network delay and network disconnection. Each node of the block chain is a completely independent running process, serial flow calculation of results is waited for each other in the consensus process, and if a certain node is in a false death state or a malicious false death state, the whole block chain can be in a paralyzed state. For example, in the second step, network communication between two nodes is not smooth, so that the number of the transaction maps of the two nodes is not one, and the system card cannot run down in the data waiting stage. This problem exists for all steps that require checking the amount of communication data.
In addition, ideally, a plurality of block chain nodes should work at the same step of the same height of the consensus process and operate synchronously, but since the distributed block chain system does not have centralized process control, in actual operation, each node may work at different heights or work at different steps of the same height, so that certain means are used to ensure that communication messages in the consensus process are not confused, and the overall pace of each node is approximately the same.
The invention provides an optimized design of some block chain bottom layer consensus processes, which is used for solving the possible problems in a block chain system and enabling the system to be more stable and reliable.
disclosure of Invention
the invention provides some solutions for reliability aiming at the problems of the existing block chain consensus system.
The invention provides a stable and reliable block chain Byzantine consensus process design method, which is characterized by comprising the following points:
(1) when the system waits for collecting data sent by other nodes, including but not limited to transaction data, block data, voting data and the like, setting timeout time, and entering a timeout processing flow after the timeout;
(2) the overtime processing distinguishes processing within the fault tolerance range from processing outside the fault tolerance range according to the collected data;
(3) The communication data in the consensus process carries height information corresponding to the data, the height is screened when the data are received, and the data which do not meet the height requirement do not enter consensus;
(4) any abnormality in the system is properly processed, and the consensus process cannot be influenced.
further, as for the feature (1), specifically:
(1) the overtime mechanism specifies the longest running time in each step, if the processing is finished in the normal time, the program is normal, and if the running time of the current step reaches the longest running time and the processing is not finished, the processing of the current step is terminated and the overtime processing flow is entered;
(2) all processing related to communication between nodes and needing to wait for return information uses a timeout mechanism;
(3) if the timeout process flow is entered, the process proceeds to the next step immediately after the process is completed, regardless of the setting of the timeout process flow.
Further, as for the feature (2), specifically:
(1) The overtime processing distinguishes processing within the fault tolerance range from processing outside the fault tolerance range according to the collected data;
(2) processing logic within the fault tolerance should coincide with processing logic that has not timed out;
(3) processing outside the fault tolerance should not stop the consensus process.
After one round of consensus is finished, no matter whether overtime is finished or normal is finished, the node immediately prepares to enter the next round of consensus, and the process is circulated, specifically:
(1) when the current node waits for the transaction information of the blockchain node, a threshold overtime mechanism is set, and the current node enters the next calculation no matter whether overtime exists or not;
(2) When the current node waits for the block information of the block building node, a threshold overtime mechanism is set, and the current node enters the next calculation no matter whether overtime exists or not;
(3) when the current node waits for the voting information of other nodes, a threshold overtime mechanism is set, and the current node enters the next calculation no matter whether the current node is overtime or not;
(4) after the current node finishes the round of consensus, the current node enters the next round of consensus calculation regardless of whether the result is successful or failed after overtime or normal completion.
further, as for the feature (3), specifically
(1) The communication data in the consensus process carries height information corresponding to the data, and the height is screened when the data are received;
(2) the current node can receive the transaction information above the current height, and the current node can receive the transaction information above the current height and store the transaction information into a corresponding cache pool by using the height as a key;
(3) And taking out the transaction information of the current height from the transaction cache in each round of consensus.
Further, as for the feature (4), specifically:
Each node can guarantee the normal operation of the system under any condition, including but not limited to the following conditions:
(1) after the node network fails and recovers, the nodes normally operate and are normally identified,
(2) the node process is restarted after being stopped accidentally, the node can run normally and participate in consensus normally,
(3) any abnormality occurs in the node, a corresponding abnormality processing flow is provided, the normal operation of the node is not influenced,
(4) All anomalies that may occur in the system are classified: system level exceptions and business level exceptions. The system level exception forces the node to exit the block chain ecosystem; for the abnormal business grade, the system adopts a proper mode to process and does not influence the operation of the system.
the invention optimizes the consensus process of the block chain by using the overtime mechanism, the cache pool of the height mark, the abnormal classification processing and other methods, and leads the system to be more stable and reliable.
description of the drawings:
Figure 1 is a classical blockchain consensus flow diagram,
TXPool is a transaction buffer pool at the system level, and a consensus process is performed from start to the processing of voting results. Wherein the TXCache in the flow is the TX cache of the transaction in this consensus.
Figure 2 is a diagram of a transaction cache design,
TXPool is a transaction cache pool at a system level and stores transaction data above the current height, TXcache is a transaction cache pool at a consensus level, the life cycle is the same as the consensus, the consensus starts exist, and the consensus disappears after one-time consensus is finished.
The specific implementation mode is as follows:
in the following description, numerous technical details are set forth in order to provide a better understanding of the present application, but it will be apparent to those of ordinary skill in the art that the present invention is not limited to these technical details and that various changes and modifications can be made based on the following embodiments.
in order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail with reference to the accompanying drawings.
the invention as shown in fig. 1 is a technology invented for the stability and reliability of a block chain consensus system, and is designed in the fields of block chain data structures, algorithm designs and the like, and the specific implementation steps are as follows:
assuming that the number of nodes is m, the current height is h, the maximum transaction processing number in each round of consensus is N, and the transaction number scanned in the current round is N.
A round of consensus starts from start. The node takes N transactions from the transaction pool TXpool, if the number of the transactions in the transaction pool is less than N, the node waits for t1 at most, and if the number of the transactions in the transaction pool exceeds t1, the node quits waiting if the number of the transactions is still less than N. The N transactions (0 < N < = N) that are fetched are marked with a height h and placed into the TXCache pool and the N transactions are deleted from the TXPool.
and converting the n transactions into a transaction mapping chart, and broadcasting the transaction mapping chart to other nodes together with the current height h information.
after the transaction mapping graph is sent out, the current node waits to receive the mapping graphs sent out by other nodes. And when the mapping map is received, checking the height, receiving only the data with the height being more than or equal to h, and putting the received data into the mapping map cache pool by using the height as a key.
And the node acquires a mapping graph set with key h from the mapping graph cache pool. If the number of transaction maps from different nodes equals the number of nodes m (including the current node's own maps), the next step is continued. And waiting when the quantity is insufficient until the set timeout t2 is reached, and then not waiting again and entering the next step.
The operation of the transaction intersection is performed regardless of the number of received transaction maps. According to the Byzantine theory, transactions that exceed two-thirds the number m of nodes are marked as public transactions.
And the building node builds blocks according to the public transaction and broadcasts the block data and the height mark h to other nodes together.
and after the other nodes calculate the public transaction, the other nodes start to wait for receiving the block, the height is checked when the block is received, the data with the height being more than or equal to h is received, and the received block uses the height as a key to be placed in the block cache pool. If a block of height h is received within the timeout t3 the next step is continued, if no block is received and the timeout has been reached the next step is continued and a vote is to be rejected on verification.
and the node takes out the block with the key h from the block cache pool for verification, and the voting result obtained after verification is broadcast to other nodes along with the height mark h.
and (4) receiving by using the cache pool with the height screening and the key as the height, setting the overtime t4 when the quantity is checked, and entering the next step when the waiting time exceeds t 4.
And the node forwards the received voting mark height h of each node.
each node receives forwarding data by using the height screening and the cache pool with the height of key, overtime time t5 is used when quantity checking is carried out, and the counting step of voting is carried out when the quantity meets the number of the nodes or the overtime time t5 is waited to be reached.
And each node obtains a final result according to the Byzantine algorithm statistics, if the votes pass, the height of the storage block is increased by 1, and if the votes do not pass, the height is not increased. And returning the transaction information which cannot be stored from the TXcache to TXpool, and directly deleting the stored transaction from the TXcache.
The transaction is taken out again from the TXPool when the next round of consensus is made.
and each step is provided with an exception handling code, so that the process cannot be influenced by special exceptions.
Claims (7)
1. a stable and reliable block chain Byzantine consensus process design method is characterized by comprising the following steps:
(1) When the system waits for collecting data sent by other nodes, including but not limited to transaction data, block data, voting data and the like, setting timeout time, and entering an timeout processing flow after the timeout;
(2) the overtime processing distinguishes processing within the fault tolerance range from processing outside the fault tolerance range according to the collected data;
(3) the communication data in the consensus process carries height information corresponding to the data, the height is screened when the data are received, the data which do not meet the height requirement do not enter consensus, different communication data have different cache pools, and the height is used as a key for storage;
(4) Any abnormality in the system is properly processed, and the consensus process cannot be influenced.
2. the method of claim 1, wherein the design method of the block chain byzantine consensus process comprises: in each step of consensus, the system specifically sets a timeout mechanism as follows:
(1) The overtime mechanism specifies the longest running time in each step, if the processing is finished in the normal time, the program is normal, and if the running time of the current step reaches the longest running time and the processing is not finished, the processing of the current step is terminated and the overtime processing flow is entered;
(2) all processing related to communication between nodes and needing to wait for return information uses a timeout mechanism;
(3) if the timeout process flow is entered, the process proceeds to the next step immediately after the process is completed, regardless of the setting of the timeout process flow.
3. the method of claim 1, wherein the design method of the block chain byzantine consensus process comprises:
(1) the overtime processing distinguishes processing within the fault tolerance range from processing outside the fault tolerance range according to the collected data;
(2) processing logic within the fault tolerance should coincide with processing logic that has not timed out;
(3) Processing outside the fault tolerance should not stop the consensus process.
4. The method of claim 1, wherein the design method of the block chain byzantine consensus process comprises: after one round of consensus is finished, no matter whether overtime is finished or normal is finished, the node immediately prepares to enter the next round of consensus, and the process is circulated, specifically:
(1) When the current node waits for the transaction information of the blockchain node, a threshold overtime mechanism is set, and the current node enters the next calculation no matter whether overtime exists or not;
(2) When the current node waits for the block information of the block building node, a threshold overtime mechanism is set, and the current node enters the next calculation no matter whether overtime exists or not;
(3) When the current node waits for the voting information of other nodes, a threshold overtime mechanism is set, and the current node enters the next calculation no matter whether the current node is overtime or not;
(4) After the current node finishes the round of consensus, the current node enters the next round of consensus calculation regardless of whether the result is successful or failed after overtime or normal completion.
5. The method of claim 1, wherein the design method of the block chain byzantine consensus process comprises:
(1) The communication data in the consensus process carries height information corresponding to the data, and the height is screened when the data are received;
(2) The current node can receive the transaction information above the current height, and the height is used as a key to be stored in a corresponding cache pool;
(3) and taking out the transaction information of the current height from the transaction cache in each round of consensus.
6. the method of claim 1, wherein the design method of the block chain byzantine consensus process comprises: each node can guarantee the normal operation of the system under any condition, including but not limited to the following conditions:
(1) After the node network fails and recovers, the nodes normally operate and are normally identified;
(2) The node process is restarted after being stopped accidentally, the node can run normally and participate in consensus normally;
(3) Any abnormality occurs in the node, and a corresponding abnormality processing flow exists, so that the normal operation of the node is not influenced;
(4) all anomalies that may occur in the system are classified: system level exceptions and business level exceptions.
7. The system level exception forces the node to exit the block chain ecosystem; for the abnormal business grade, the system adopts a proper mode to process and does not influence the operation of the system.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810481158.3A CN110569395A (en) | 2018-05-18 | 2018-05-18 | stable and reliable block chain Byzantine consensus process design method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810481158.3A CN110569395A (en) | 2018-05-18 | 2018-05-18 | stable and reliable block chain Byzantine consensus process design method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110569395A true CN110569395A (en) | 2019-12-13 |
Family
ID=68771812
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810481158.3A Pending CN110569395A (en) | 2018-05-18 | 2018-05-18 | stable and reliable block chain Byzantine consensus process design method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110569395A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111598389A (en) * | 2020-04-09 | 2020-08-28 | 广东工业大学 | Block chain-based trading system for preventing bill market risk |
| CN113810465A (en) * | 2021-08-12 | 2021-12-17 | 清华大学 | Asynchronous binary consensus method and device |
| CN113821569A (en) * | 2021-09-30 | 2021-12-21 | 广州智链未来科技有限公司 | Block chain consensus method and block chain |
| US11250021B2 (en) | 2020-04-17 | 2022-02-15 | International Business Machines Corporation | Faster view change for blockchain |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106445711A (en) * | 2016-08-28 | 2017-02-22 | 杭州云象网络技术有限公司 | Byzantine-fault-tolerant consensus method applied to block chain |
| CN106878071A (en) * | 2017-01-25 | 2017-06-20 | 上海钜真金融信息服务有限公司 | A kind of block chain common recognition mechanism based on Raft algorithms |
| CN107016611A (en) * | 2017-03-29 | 2017-08-04 | 杭州秘猿科技有限公司 | A kind of transaction manufacture timeout control method based on block chain |
| CN107146087A (en) * | 2017-04-11 | 2017-09-08 | 广东网金控股股份有限公司 | A kind of quick common recognition bookkeeping methods and system based on block chain alliance chain |
| CN107423152A (en) * | 2017-04-24 | 2017-12-01 | 杭州趣链科技有限公司 | A kind of block chain common recognition node automatic recovery method |
| CN107424066A (en) * | 2017-07-19 | 2017-12-01 | 武汉凤链科技有限公司 | A kind of method and its system of mechanism of being built a consensus based on the magnitude of value |
| CN107688945A (en) * | 2017-08-11 | 2018-02-13 | 杭州秘猿科技有限公司 | A kind of efficient license chain based on delaying state common recognition |
-
2018
- 2018-05-18 CN CN201810481158.3A patent/CN110569395A/en active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106445711A (en) * | 2016-08-28 | 2017-02-22 | 杭州云象网络技术有限公司 | Byzantine-fault-tolerant consensus method applied to block chain |
| CN106878071A (en) * | 2017-01-25 | 2017-06-20 | 上海钜真金融信息服务有限公司 | A kind of block chain common recognition mechanism based on Raft algorithms |
| CN107016611A (en) * | 2017-03-29 | 2017-08-04 | 杭州秘猿科技有限公司 | A kind of transaction manufacture timeout control method based on block chain |
| CN107146087A (en) * | 2017-04-11 | 2017-09-08 | 广东网金控股股份有限公司 | A kind of quick common recognition bookkeeping methods and system based on block chain alliance chain |
| CN107423152A (en) * | 2017-04-24 | 2017-12-01 | 杭州趣链科技有限公司 | A kind of block chain common recognition node automatic recovery method |
| CN107424066A (en) * | 2017-07-19 | 2017-12-01 | 武汉凤链科技有限公司 | A kind of method and its system of mechanism of being built a consensus based on the magnitude of value |
| CN107688945A (en) * | 2017-08-11 | 2018-02-13 | 杭州秘猿科技有限公司 | A kind of efficient license chain based on delaying state common recognition |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111598389A (en) * | 2020-04-09 | 2020-08-28 | 广东工业大学 | Block chain-based trading system for preventing bill market risk |
| CN111598389B (en) * | 2020-04-09 | 2023-04-28 | 广东工业大学 | Transaction system for preventing bill market risk based on blockchain |
| US11250021B2 (en) | 2020-04-17 | 2022-02-15 | International Business Machines Corporation | Faster view change for blockchain |
| US11775556B2 (en) | 2020-04-17 | 2023-10-03 | International Business Machines Corporation | Faster view change for blockchain |
| CN113810465A (en) * | 2021-08-12 | 2021-12-17 | 清华大学 | Asynchronous binary consensus method and device |
| CN113821569A (en) * | 2021-09-30 | 2021-12-21 | 广州智链未来科技有限公司 | Block chain consensus method and block chain |
| CN113821569B (en) * | 2021-09-30 | 2024-02-06 | 广州智链未来科技有限公司 | Block chain consensus method and block chain |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110569395A (en) | stable and reliable block chain Byzantine consensus process design method | |
| US5884018A (en) | Method and apparatus for distributed agreement on processor membership in a multi-processor system | |
| CN109308227B (en) | Fault detection control method and related equipment | |
| WO1998033121A9 (en) | Method and apparatus for split-brain avoidance in a multi-process or system | |
| CN108596768A (en) | A kind of distributed transaction processing method, apparatus and system | |
| WO2022121612A1 (en) | Information processing method and apparatus for blockchain network, and device and storage medium | |
| CN111091106A (en) | Image clustering method and device, storage medium and electronic device | |
| CN110930254A (en) | Data processing method, device, terminal and medium based on block chain | |
| CN110808839A (en) | Processing method, device, equipment and medium for block chain abnormal data | |
| CA2275242A1 (en) | Method and apparatus for tolerance of lost timer ticks during recovery of a multi-processor system | |
| CN105808619A (en) | Task redoing method based on influence analysis, influence analysis calculation device and one-key reset device | |
| CN116723085A (en) | Service conflict processing method and device, storage medium and electronic device | |
| CN113438092B (en) | Transaction broadcasting method and system | |
| CN108829533A (en) | A kind of fault-tolerance detection method of intelligent computer systems | |
| CN115705259A (en) | Fault processing method, related device and storage medium | |
| CN111770178A (en) | Leader node election method and system | |
| CN111063092B (en) | Lottery drawing method and device based on block chain, electronic equipment and storage medium | |
| CN112053150A (en) | Data processing method, device and storage medium | |
| CN113032483B (en) | Cross-platform data asset sharing method and device and electronic equipment | |
| CN116431459B (en) | Distributed log link tracking data processing method and device | |
| CN117056914B (en) | Endogenous security processing method and system based on heterogeneous operating system | |
| CN113360688B (en) | Method, device and system for constructing information base | |
| CN113206882B (en) | Consensus method, computer device and storage medium | |
| JPH022747A (en) | Withdrawal frame recognition device | |
| CN117112279A (en) | Fusing method and device of data link |
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 |