CN109246194B - Practical Byzantine fault-tolerant block chain consensus method and system based on multiple leader nodes - Google Patents
Practical Byzantine fault-tolerant block chain consensus method and system based on multiple leader nodes Download PDFInfo
- Publication number
- CN109246194B CN109246194B CN201810914022.7A CN201810914022A CN109246194B CN 109246194 B CN109246194 B CN 109246194B CN 201810914022 A CN201810914022 A CN 201810914022A CN 109246194 B CN109246194 B CN 109246194B
- Authority
- CN
- China
- Prior art keywords
- consensus
- node
- leader
- nodes
- block
- 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
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- 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
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
Abstract
The invention discloses a practical Byzantine fault-tolerant block chain consensus method and a practical Byzantine fault-tolerant block chain consensus system based on multiple leader nodes, wherein the method comprises the following steps: connecting the consensus node to the kafka cluster, and uploading the transaction received by the consensus node and corresponding consensus node information to the kafka cluster; performing identical cutting on the corresponding consensus nodes, thereby packaging the corresponding transactions into blocks; and performing single matching grouping on the non-leader nodes according to the number of the leader nodes, so that each group comprises one leader node, and performing PBFT in the groups, thereby keeping synchronization with the blocks corresponding to the leader nodes. Compared with the prior art, the method and the device solve the problem that the PBFT algorithm cannot be practical due to the fact that the number of nodes in the network is large due to too high complexity, and meanwhile, the time for generating and confirming a block by the block chain system is shortened, so that the throughput of the whole block chain system is greatly improved, and the method and the device have high practicability.
Description
Technical Field
The invention relates to a practical Byzantine fault-tolerant block chain consensus method and a practical Byzantine fault-tolerant block chain consensus system based on multiple leader nodes.
Background
And when the hot topic block chain of the fire is adopted, the system is a decentralized value transfer system. Since there is no centralized third party authority, the authentication and validation of transaction information requires the co-participation of network-wide nodes. A blockchain, which is a data structure that stores data in time sequence, may support different consensus mechanisms. The consensus mechanism is an important component of the blockchain technique. The goal of the blockchain consensus mechanism is to have all honest nodes maintain a consistent blockchain view while meeting consistency and validity.
At present, algorithms, such as a workload certification algorithm (POW), a stock right certification (POS), a practical byzantine fault-tolerant algorithm (PBFT), and the like, have appeared for a consensus mechanism, where the PBFT is widely used, but the complexity of the current PBFT algorithm is high, which is mainly reflected in that a network node is too many, and it takes much time to confirm a block, which is not beneficial to improve the throughput of the whole block chain system, so the practicability is not high.
Disclosure of Invention
In order to solve the above problems, an object of the present invention is to provide a practical byzantine fault-tolerant block chain consensus method and system based on multiple leader nodes, which can effectively reduce the complexity of the conventional PBFT algorithm, facilitate the improvement of the throughput of the whole block chain system, and have high practicability.
In order to make up for the defects of the prior art, the invention adopts the technical scheme that:
the practical Byzantine fault-tolerant block chain consensus method based on the multiple leader nodes comprises the following steps:
connecting the consensus node to the kafka cluster, and uploading the transaction received by the consensus node and corresponding consensus node information to the kafka cluster;
performing identical cutting on the corresponding consensus nodes, thereby packaging the corresponding transactions into blocks; the consensus node is a leader node;
and performing single matching grouping on the non-leader nodes according to the number of the leader nodes, so that each group comprises one leader node, and performing PBFT in the groups, thereby keeping synchronization with the blocks corresponding to the leader nodes.
Further, performing the same cut on the corresponding consensus node to package the corresponding transaction into blocks, comprising: before the consensus node is cut, sending a TTC synchronous message to a kafka cluster, when the consensus node receives the TTC synchronous message for the first time, starting cutting and packaging the previous transaction into a block N, and starting packaging the subsequent transaction in a block N +1 form; wherein, N is the block ordinal number.
Further, performing PBFT within the group to maintain synchronization with the blocks corresponding to the leader node, comprising:
the transactions in the block corresponding to the leader node are sorted and stored into a list, and the list is broadcasted to the whole network so as to be diffused to the non-leader nodes in the group;
for each non-leader node, simulating and executing sequencing transaction according to the list and generating a corresponding new block, calculating the hash abstract of the block based on the transaction result and broadcasting the hash abstract to the whole network;
when a certain non-leader node receives 2f hash digests equal to the node, broadcasting a commit message to the whole network;
when a certain non-leader node receives 2f +1 commit messages, submitting corresponding new blocks and transactions thereof and uploading the new blocks and the transactions to a local block chain and a state database;
wherein f is the number of Byzantine fault-tolerant nodes.
Preferably, the number of nodes per subgroup does not exceed 100.
A practical Byzantine fault-tolerant block chain consensus system based on multiple leader nodes comprises:
the linking module is used for enabling the consensus node to be connected to the kafka cluster, and uploading the transaction received by the consensus node and corresponding consensus node information to the kafka cluster;
the processing module is used for carrying out identical cutting on the corresponding consensus nodes so as to pack the corresponding transactions into blocks; the consensus node is a leader node;
and the identification module is used for performing single matching grouping on the non-leader nodes according to the number of the leader nodes, so that each group comprises one leader node, and performing PBFT in the group, thereby keeping synchronization with the blocks corresponding to the leader nodes.
Further, the processing module performs the same cut on the corresponding consensus node, thereby packing the corresponding transaction into blocks, including: before the consensus node is cut, sending a TTC synchronous message to a kafka cluster, when the consensus node receives the TTC synchronous message for the first time, starting cutting and packaging the previous transaction into a block N, and starting packaging the subsequent transaction in a block N +1 form; wherein, N is the block ordinal number.
Further, the identifying module, executing PBFT within the group to maintain synchronization with the block corresponding to the leader node, includes:
the transactions in the block corresponding to the leader node are sorted and stored into a list, and the list is broadcasted to the whole network so as to be diffused to the non-leader nodes in the group;
for each non-leader node, simulating and executing sequencing transaction according to the list and generating a corresponding new block, calculating the hash abstract of the block based on the transaction result and broadcasting the hash abstract to the whole network;
when a certain non-leader node receives 2f hash digests equal to the node, broadcasting a commit message to the whole network;
when a certain non-leader node receives 2f +1 commit messages, submitting corresponding new blocks and transactions thereof and uploading the new blocks and the transactions to a local block chain and a state database;
wherein f is the number of Byzantine fault-tolerant nodes.
Preferably, the number of nodes per subgroup does not exceed 100.
The invention has the beneficial effects that: the method improves the traditional PBFT algorithm, carries out overall connection through kafka clusters, and carries out information uploading on common identification nodes through actual transactions, ensures that the corresponding transactions are packaged into corresponding blocks, thereby ensuring that a plurality of completely identical leader nodes are generated, then carries out grouping and applies the PBFT algorithm in the group, thereby ensuring that all nodes realize synchronous common identification.
Drawings
The following description of the preferred embodiments of the present invention will be made in conjunction with the accompanying drawings.
Fig. 1 is a schematic diagram of the structural principle of the practical byzantine fault-tolerant block chain consensus system based on multiple leader nodes.
Detailed Description
Referring to fig. 1, the practical byzantine fault-tolerant block chain consensus method based on multiple leader nodes of the present invention includes the following steps:
connecting the consensus node to the kafka cluster, and uploading the transaction received by the consensus node and corresponding consensus node information to the kafka cluster;
performing identical cutting on the corresponding consensus nodes, thereby packaging the corresponding transactions into blocks; the consensus node is a leader node;
and performing single matching grouping on the non-leader nodes according to the number of the leader nodes, so that each group comprises one leader node, and performing PBFT in the groups, thereby keeping synchronization with the blocks corresponding to the leader nodes.
Specifically, Kafka is an open source stream processing platform developed by the Apache software foundation, written by Scala and Java; kafka is a high-throughput distributed publish-subscribe messaging system that can handle all the action flow data in a consumer-scale website. Such actions (including web browsing, searching, and other user actions) are key factors to many social functions on modern networks, and these data are usually addressed by processing logs and log aggregations due to throughput requirements; this is a viable solution to the limitations of Hadoop-like log data and offline analysis systems, but which require real-time processing; kafka aims to unify online and offline message processing through a parallel loading mechanism of Hadoop, and also aims to provide real-time messages through clustering;
obviously, as shown in fig. 1, one consensus node can receive multiple transactions, and only need to upload and cut correspondingly when the transactions arrive;
the embodiment improves the traditional PBFT algorithm, carries out overall connection through kafka clusters, and uploads information through actual transactions and consensus nodes to ensure that the corresponding transactions are packed into corresponding blocks, thereby ensuring that a plurality of completely identical leader nodes are generated, and then carries out grouping and applies the PBFT algorithm in the group, thereby realizing synchronous consensus of all nodes;
and the application of the PBFT algorithm within a group is based on small scale, i.e. typically the number of nodes per small group does not exceed 100, which facilitates the execution of the PBFT algorithm.
Further, performing the same cut on the corresponding consensus node to package the corresponding transaction into blocks, comprising: before the consensus node is cut, sending a TTC synchronous message to a kafka cluster, when the consensus node receives the TTC synchronous message for the first time, starting cutting and packaging the previous transaction into a block N, and starting packaging the subsequent transaction in a block N +1 form; wherein, N is the block ordinal number.
Further, performing PBFT within the group to maintain synchronization with the blocks corresponding to the leader node, comprising:
the transactions in the block corresponding to the leader node are sorted and stored into a list, and the list is broadcasted to the whole network so as to be diffused to the non-leader nodes in the group;
for each non-leader node, simulating and executing sequencing transaction according to the list and generating a corresponding new block, calculating the hash abstract of the block based on the transaction result and broadcasting the hash abstract to the whole network;
when a certain non-leader node receives 2f hash digests equal to the node, broadcasting a commit message to the whole network;
when a certain non-leader node receives 2f +1 commit messages, submitting corresponding new blocks and transactions thereof and uploading the new blocks and the transactions to a local block chain and a state database;
wherein f is the number of Byzantine fault-tolerant nodes, and in fact, if f nodes in a block chain system are damaged but data synchronization and safety are not affected, the number of the nodes in the network needs to be at least 3f + 1; in the field, the Hash in the Hash digest is a Hash, i.e., a Hash digest function value, which is relatively common, and therefore is not described herein again; on the other hand, the commit message is a Broker message storage file, is an intermediate quantity in the PBFT, and is used for judging whether the block and the transaction thereof are completed, thereby performing corresponding data upload.
In this embodiment, all nodes needing to participate in consensus are connected to a cluster of a kafka message queue, a transaction initiated by a user is broadcasted to a certain consensus node in a broadcasting mode, then the consensus node replaces the received transaction and the number of the node in the kafka message queue, when partial transactions exist in the kafka, the transaction is cut and packaged into a block, and since the consensus nodes connected to the kafka are cut in the same mode, the consensus nodes share the same block, and the nodes become leader nodes in the next step in the PBFT algorithm. And other nodes which are not connected to the kafka cluster, namely non-leader nodes, are grouped according to the number of leader nodes connected to the kafka cluster, and the PBFT algorithm is adopted in the group, so that the nodes are synchronized with the block corresponding to the leader node.
In order to ensure that the blocks cut by the leader node are completely consistent, a synchronization signal message, namely a TTC synchronization message, is introduced; in fact, each node detects that the time when the transaction reaches the kafka cluster is not exactly the same, and therefore a new transaction may be initiated and added to kafka within this time difference, and it may cut this new transaction, and thus it cannot be guaranteed that all the nodes cut the same block, and the consensus fails, as can be seen from fig. 1, when the transaction 36 is placed in kafka, node 0 immediately detects and decides to cut, and if ignoring the incoming TTC synchronization message, it can be seen that node 2 is detected at a later point, and although this time difference is small, a new transaction 37 is generated, and then the block of node 0 will not include the transaction 37, and the block of node 2 will include, and thus they will not be consistent. Assuming that block 4 and the previous blocks have been properly cut in fig. 1, the case of cutting the fifth block is now focused: when node 0 is about to cut the fifth block, it does not actually cut the fifth block to form a block immediately, but first sends its own TTC-5 sync message to the kafka message queue (TTC-X denotes the sync message sent by cutting the xth block, and here denotes the sync message sent by cutting the 5 th block), then node 2 similarly sends the corresponding sync message before cutting, and then each node will pack the previous transaction into block 5 when encountering the first TTC-5 sync message during the actual cutting process, and take the subsequent transaction as the content of block 6, and then the TTC-5 sync message received later will be ignored entirely, i.e. only the first sync message will be taken as the criterion; by the method, the content of all the cut blocks is ensured to be identical, so that completely consistent leader nodes are generated, and all non-leader nodes synchronized by the PBFT algorithm can obtain the same blocks.
In this embodiment, after a plurality of leader nodes are generated, other non-leader nodes in the network are dynamically grouped, that is, in each consensus process, the grouping is randomly grouped again instead of keeping the same group for consensus, so as to reduce some potential safety hazards that may be caused by a static group.
Referring to fig. 1, a multi-leader node-based practical byzantine fault-tolerant block chain consensus system includes:
the linking module is used for enabling the consensus node to be connected to the kafka cluster, and uploading the transaction received by the consensus node and corresponding consensus node information to the kafka cluster;
the processing module is used for carrying out identical cutting on the corresponding consensus nodes so as to pack the corresponding transactions into blocks; the consensus node is a leader node;
and the identification module is used for performing single matching grouping on the non-leader nodes according to the number of the leader nodes, so that each group comprises one leader node, and performing PBFT in the group, thereby keeping synchronization with the blocks corresponding to the leader nodes.
Specifically, the traditional PBFT algorithm is improved, the kafka cluster is used for carrying out overall connection, information uploading is carried out on the consensus nodes through actual transactions, the corresponding transactions are packaged into the corresponding blocks, so that the generation of a plurality of completely identical leader nodes is guaranteed, then grouping is carried out, and the PBFT algorithm is applied in the group, so that all the nodes can realize synchronous consensus.
Further, the processing module performs the same cut on the corresponding consensus node, thereby packing the corresponding transaction into blocks, including: before the consensus node is cut, sending a TTC synchronous message to a kafka cluster, when the consensus node receives the TTC synchronous message for the first time, starting cutting and packaging the previous transaction into a block N, and starting packaging the subsequent transaction in a block N +1 form; wherein, N is the block ordinal number.
Further, the identifying module, executing PBFT within the group to maintain synchronization with the block corresponding to the leader node, includes:
the transactions in the block corresponding to the leader node are sorted and stored into a list, and the list is broadcasted to the whole network so as to be diffused to the non-leader nodes in the group;
for each non-leader node, simulating and executing sequencing transaction according to the list and generating a corresponding new block, calculating the hash abstract of the block based on the transaction result and broadcasting the hash abstract to the whole network;
when a certain non-leader node receives 2f hash digests equal to the node, broadcasting a commit message to the whole network;
when a certain non-leader node receives 2f +1 commit messages, submitting corresponding new blocks and transactions thereof and uploading the new blocks and the transactions to a local block chain and a state database;
wherein f is the number of Byzantine fault-tolerant nodes.
Preferably, the number of nodes per subgroup does not exceed 100.
While the preferred embodiments and basic principles of the present invention have been described in detail, it will be understood by those skilled in the art that the invention is not limited to the embodiments, but is intended to cover various modifications, equivalents and alternatives falling within the scope of the invention as claimed.
Claims (8)
1. The practical Byzantine fault-tolerant block chain consensus method based on the multiple leader nodes is characterized by comprising the following steps of:
connecting the consensus node to the kafka cluster, and uploading the transaction received by the consensus node and corresponding consensus node information to the kafka cluster;
performing identical cutting on the corresponding consensus nodes, thereby packaging the corresponding transactions into blocks; the consensus node is a leader node;
and performing single matching grouping on the non-leader nodes according to the number of the leader nodes, so that each group comprises one leader node, and performing PBFT in the groups, thereby keeping synchronization with the blocks corresponding to the leader nodes.
2. The multi-leader node based practical byzantine fault-tolerant blockchain consensus method of claim 1, wherein identically cutting corresponding consensus nodes to pack corresponding transactions into blocks comprises: before the consensus node is cut, sending a TTC synchronous message to a kafka cluster, when the consensus node receives the TTC synchronous message for the first time, starting cutting and packaging the previous transaction into a block N, and starting packaging the subsequent transaction in a block N +1 form; wherein, N is the block ordinal number.
3. The method of claim 1, wherein performing PBFT within a group to maintain synchronization with the blocks corresponding to the leader node comprises:
the transactions in the block corresponding to the leader node are sorted and stored into a list, and the list is broadcasted to the whole network so as to be diffused to the non-leader nodes in the group;
for each non-leader node, simulating and executing sequencing transaction according to the list and generating a corresponding new block, calculating the hash abstract of the block based on the transaction result and broadcasting the hash abstract to the whole network;
when a certain non-leader node receives 2f hash digests equal to the node, broadcasting a commit message to the whole network;
when a certain non-leader node receives 2f +1 commit messages, submitting corresponding new blocks and transactions thereof and uploading the new blocks and the transactions to a local block chain and a state database;
wherein f is the number of Byzantine fault-tolerant nodes.
4. The multi-leader node-based practical byzantine fault-tolerant blockchain consensus method of claim 1, wherein the number of nodes per subgroup does not exceed 100.
5. A multi-leader node-based practical byzantine fault-tolerant blockchain consensus system applying the consensus method according to any one of claims 1 to 4, comprising:
the linking module is used for enabling the consensus node to be connected to the kafka cluster, and uploading the transaction received by the consensus node and corresponding consensus node information to the kafka cluster;
the processing module is used for carrying out identical cutting on the corresponding consensus nodes so as to pack the corresponding transactions into blocks; the consensus node is a leader node;
and the identification module is used for performing single matching grouping on the non-leader nodes according to the number of the leader nodes, so that each group comprises one leader node, and performing PBFT in the group, thereby keeping synchronization with the blocks corresponding to the leader nodes.
6. The multi-leader node based practical byzantine fault-tolerant blockchain consensus system as claimed in claim 5, wherein said processing module performs a same cut on corresponding consensus nodes to pack corresponding transactions into blocks, comprising: before the consensus node is cut, sending a TTC synchronous message to a kafka cluster, when the consensus node receives the TTC synchronous message for the first time, starting cutting and packaging the previous transaction into a block N, and starting packaging the subsequent transaction in a block N +1 form; wherein, N is the block ordinal number.
7. The multi-leader node based practical byzantine fault-tolerant blockchain consensus system as claimed in claim 5, wherein the identification module, performing PBFT within a group to maintain synchronization with the blocks corresponding to the leader node, comprises:
the transactions in the block corresponding to the leader node are sorted and stored into a list, and the list is broadcasted to the whole network so as to be diffused to the non-leader nodes in the group;
for each non-leader node, simulating and executing sequencing transaction according to the list and generating a corresponding new block, calculating the hash abstract of the block based on the transaction result and broadcasting the hash abstract to the whole network;
when a certain non-leader node receives 2f hash digests equal to the node, broadcasting a commit message to the whole network;
when a certain non-leader node receives 2f +1 commit messages, submitting corresponding new blocks and transactions thereof and uploading the new blocks and the transactions to a local block chain and a state database;
wherein f is the number of Byzantine fault-tolerant nodes.
8. The multi-leader node based practical Byzantine fault-tolerant blockchain consensus system as claimed in claim 5, wherein the number of nodes per subgroup does not exceed 100.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810914022.7A CN109246194B (en) | 2018-08-13 | 2018-08-13 | Practical Byzantine fault-tolerant block chain consensus method and system based on multiple leader nodes |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810914022.7A CN109246194B (en) | 2018-08-13 | 2018-08-13 | Practical Byzantine fault-tolerant block chain consensus method and system based on multiple leader nodes |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109246194A CN109246194A (en) | 2019-01-18 |
| CN109246194B true CN109246194B (en) | 2021-06-08 |
Family
ID=65070359
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810914022.7A Active CN109246194B (en) | 2018-08-13 | 2018-08-13 | Practical Byzantine fault-tolerant block chain consensus method and system based on multiple leader nodes |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109246194B (en) |
Families Citing this family (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109788060B (en) * | 2019-01-22 | 2021-05-07 | 曲阜师范大学 | Cloud data sharing and updating method based on block chain |
| CN110113388B (en) * | 2019-04-17 | 2020-01-14 | 四川大学 | Improved clustering algorithm-based block chain system consensus method and device |
| EP3970343A4 (en) * | 2019-05-15 | 2022-12-28 | Nokia Technologies OY | Parallel multi-blocks creation scheme for blockchain |
| KR102273160B1 (en) * | 2019-08-01 | 2021-07-05 | 주식회사 블룸테크놀로지 | Ledger system of directed acyclic graph - account-wise transaction chain with byzantine fault tolerance |
| CN110474986B (en) * | 2019-08-20 | 2022-08-12 | 深圳前海微众银行股份有限公司 | Consensus method, device and system based on block chain system |
| WO2021134470A1 (en) * | 2019-12-31 | 2021-07-08 | 西门子股份公司 | Blockchain system, data processing method, computing device and medium |
| US11250021B2 (en) | 2020-04-17 | 2022-02-15 | International Business Machines Corporation | Faster view change for blockchain |
| CN113538138A (en) * | 2020-04-17 | 2021-10-22 | 中国移动通信集团有限公司 | Method and device for generating grouping consensus model and computer equipment |
| CN112118321B (en) * | 2020-09-24 | 2023-06-06 | 北京工业大学 | Practical Bayesian fault-tolerant consensus mechanism optimization system for industrial block chain |
| CN112433885B (en) * | 2020-11-19 | 2021-09-10 | 腾讯科技（深圳）有限公司 | Block chain consensus processing method and device, electronic equipment and storage medium |
| CN112860482B (en) * | 2021-01-27 | 2021-11-12 | 西南林业大学 | Block chain consensus performance optimization method |
| CN112953733B (en) * | 2021-03-16 | 2022-08-26 | 昆明理工大学 | Data management block chain communication resource integration consensus method |
| CN113922965B (en) * | 2021-10-09 | 2024-04-16 | 筹远(上海)信息科技有限公司 | Block chain data consensus method and device in Bayesian scene |
| CN114640466B (en) * | 2022-03-15 | 2023-10-20 | 重庆邮电大学 | Layered architecture-oriented PBFT consensus node dynamic adjustment method |
| CN114448900B (en) * | 2022-04-02 | 2022-08-02 | 南京邮电大学 | SDN controller interaction method and system based on extended raft algorithm |
| CN114866562B (en) * | 2022-05-27 | 2023-06-09 | 山东省计算中心（国家超级计算济南中心） | Block chain consensus method and system for electric power energy system |
| CN117221332B (en) * | 2023-06-08 | 2024-04-12 | 天津大学 | High-robustness exchange packaging method based on multi-leader Bayesian-busy-family fault-tolerant consensus |
| CN116743771B (en) * | 2023-08-11 | 2023-11-03 | 武汉趣链数字科技有限公司 | Block chain consensus method, apparatus, electronic device and computer readable storage medium |
Citations (5)
| 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 |
| CN106850802A (en) * | 2017-02-04 | 2017-06-13 | 先锋支付有限公司 | A kind of block chain generation method, distributed node and block chain network |
| CN107040594A (en) * | 2017-04-12 | 2017-08-11 | 山大地纬软件股份有限公司 | The method and device of license block chain node access based on PBFT |
| CN107579848A (en) * | 2017-08-30 | 2018-01-12 | 上海保险交易所股份有限公司 | The method that common recognition node is dynamically changed in practical Byzantine failure tolerance common recognition mechanism |
| CN108182635A (en) * | 2017-12-18 | 2018-06-19 | 深圳前海微众银行股份有限公司 | Block chain common recognition method, system and computer readable storage medium |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107683488B (en) * | 2015-04-05 | 2023-09-05 | 数字资产(瑞士)股份有限公司 | Digital asset intermediation electronic settlement platform |
-
2018
- 2018-08-13 CN CN201810914022.7A patent/CN109246194B/en active Active
Patent Citations (5)
| 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 |
| CN106850802A (en) * | 2017-02-04 | 2017-06-13 | 先锋支付有限公司 | A kind of block chain generation method, distributed node and block chain network |
| CN107040594A (en) * | 2017-04-12 | 2017-08-11 | 山大地纬软件股份有限公司 | The method and device of license block chain node access based on PBFT |
| CN107579848A (en) * | 2017-08-30 | 2018-01-12 | 上海保险交易所股份有限公司 | The method that common recognition node is dynamically changed in practical Byzantine failure tolerance common recognition mechanism |
| CN108182635A (en) * | 2017-12-18 | 2018-06-19 | 深圳前海微众银行股份有限公司 | Block chain common recognition method, system and computer readable storage medium |
Non-Patent Citations (2)
| Title |
|---|
| 区块链共识机制研究与分析;刘童桐;《信息通信技术与政策》;20180731;全文 * |
| 国外区块链研究主题及展望;程晨等;《电子政务》;20180630;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109246194A (en) | 2019-01-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109246194B (en) | Practical Byzantine fault-tolerant block chain consensus method and system based on multiple leader nodes | |
| CN111625593B (en) | Block chain-based data processing method and device and computer equipment | |
| KR102566892B1 (en) | Blockchain consensus method, device and system | |
| US20190034465A1 (en) | Blockchain logging of data from multiple systems | |
| CN113347164B (en) | Block chain-based distributed consensus system, method, device and storage medium | |
| JP2022185070A (en) | Method for high-speed transmission in block chain network and special network node | |
| AU2012203537A1 (en) | Method and system for automated system migration | |
| CN112118321A (en) | Practical Byzantine fault-tolerant consensus mechanism optimization system of industrial block chain | |
| CN111314067A (en) | Block storage method and device, computer equipment and storage medium | |
| CN114218612B (en) | Consensus method suitable for alliance chain high-frequency transaction scene | |
| CN110324331B (en) | Block chain-based identity authentication method for safety and stability control terminal of power system | |
| CN111092896A (en) | Food traceability distributed data synchronization method based on optimized PAXOS | |
| CN109325077A (en) | A kind of system that number storehouse in real time is realized based on canal and kafka | |
| CN111698315A (en) | Data processing method and device for block and computer equipment | |
| CN111798234B (en) | Lightweight block chain system and construction method | |
| US11025688B1 (en) | Automated streaming data platform | |
| CN110505084B (en) | Block chain packing node consensus electing method | |
| CN115292414A (en) | Method for synchronizing service data to data bins | |
| CN112351106B (en) | Service grid platform containing event grid and communication method thereof | |
| EP2025133B1 (en) | Repository synchronization in a ranked repository cluster | |
| CN110555064A (en) | data service system and method for insurance business | |
| EP3349416B1 (en) | Relationship chain processing method and system, and storage medium | |
| CN113609229B (en) | Method and device for fast log replication in Fabric block chain | |
| CN115757642A (en) | Data synchronization method and device based on filing log file | |
| CN113704813A (en) | Maritime work equipment secondary identification data storage method and system, and verification method and system |
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 |