CN111586102B - BFT consensus-based alliance chain networking method - Google Patents
BFT consensus-based alliance chain networking method Download PDFInfo
- Publication number
- CN111586102B CN111586102B CN202010264747.3A CN202010264747A CN111586102B CN 111586102 B CN111586102 B CN 111586102B CN 202010264747 A CN202010264747 A CN 202010264747A CN 111586102 B CN111586102 B CN 111586102B
- Authority
- CN
- China
- Prior art keywords
- message
- node
- connection
- nodes
- pool
- 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
- H04L67/104—Peer-to-peer [P2P] networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- 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
-
- 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/14—Session management
- H04L67/141—Setup of application sessions
-
- 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/14—Session management
- H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
- H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Health & Medical Sciences (AREA)
- Cardiology (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a BFT consensus-based alliance chain networking method, and the alliance chain nodes configure connection nodes through configuration files when networking, and meet the following requirements: the number of node connections is more than or equal to 2; the connected nodes can be dynamically updated through the configuration files; when a new node joins the alliance chain, the security of the node connection is ensured through handshake confirmation and certificate verification. When receiving the message, the node compares the message with the message in the message pool, if the message is a new message, the new message is put into the message pool to be processed, and the new message is broadcasted to other nodes connected with the new message, so that the message is broadcasted to the nodes of the whole network. The invention optimizes the BFT consensus full-connection network into a mixed connection, reduces the complexity of the connected O (N ^2) to O (N), ensures the broadcast of messages in the whole network, carries out related transformation on the traditional BFT consensus process, realizes the correctness of the BFT consensus algorithm in the networking mode, ensures the efficiency of the BFT consensus algorithm and enables a block chain to be applied to a larger-scale scene.
Description
Technical Field
The invention relates to a block chain technology, in particular to a BFT consensus-based alliance chain networking method.
Background
In the BFT consensus algorithm, the networks of member organizations are required to interwork, i.e., the P2P network is shown in fig. 1. However, in the practical application process, the networking mode is very complex, the network access relationship is n × n-1/2, the complexity is O (n ^2), n is the number of the block chain link points, when the block chain network nodes increase, the efficiency of the block chain decreases very significantly, for example, 100 nodes, and the network access relationship is 4950, that is, the networking mode is not suitable for a large-scale application scenario; in addition, the networking mode also makes the block chain network have very poor expansibility. Based on the above analysis, the requirement for a networking mode capable of meeting practical application scenarios is very urgent.
Disclosure of Invention
The invention aims to provide a BFT consensus-based alliance chain networking method aiming at the defects of the prior art.
In order to achieve the purpose, the invention adopts the following technical scheme: a BFT consensus-based federation chain networking method comprises the following steps:
when the alliance link node is networked, the connection node is configured through the configuration file, and the following conditions are met: the node connection number is more than or equal to 2, namely, any node is ensured to be connected with at least two other nodes; the connected nodes can be dynamically updated through the configuration files;
each alliance link node is provided with a connection pool and a message pool;
when a new node joins a alliance chain, a target node needing to be connected is obtained through a target node list of a configuration file, then connection operation is initiated, and the identities of the other sides are mutually verified through an interactive message with a certificate signature, so that an access authorization mechanism of network nodes of the alliance chain is realized;
when the nodes of the alliance chain network are changed, updating the connection pool and the configuration file of the nodes;
when receiving the message, the node compares the message with the message in the message pool, if the message is received, the message is directly returned, if the message is a new message, the new message is put into the message pool to be processed, and the new message is broadcasted to other nodes connected with the new message, so that the message is broadcasted to the nodes of the whole network.
Further, the new node may be a consensus node or a non-consensus node, and the role of the node is specified by configuration.
Further, when a new node joins the federation chain, the connection steps are as follows:
starting a new node, and initiating link operation to a target node according to a configuration file; starting a timer for triggering a plurality of attempted connections; creating a connection coroutine for processing connection interaction with a target node; initiating a handshake operation to apply for connection resources; generating a handshake message IdentityMsg with a certificate signature, sending the IdentityMsg, and waiting for a return message of a target node;
the target node carries out signature verification on the received IdentityMsg, if the verification is passed, an Rsp message with a certificate signature is sent, and otherwise, an Rsp message refusing connection is sent;
the new node analyzes the received Rsp message, and if the Rsp message is a connection rejection message, the new node directly returns the Rsp message; if the message is the Rsp message with the signature, performing signature verification, if the certificate verification fails, sending a connection refusing message to the target node, and if the certificate verification passes, sending a verification passing message;
the target node analyzes the received message, and if the message is a connection refusal message, the message is directly returned; if the verification passes, sending a connection completion message, and updating the connection pool of the user;
and after receiving the connection completion message of the target node, the new node updates the connection pool of the new node to complete the connection.
Further, when the node completes establishing connection, a heartbeat detection coroutine is started, and the connection condition of the connection pool is detected at regular time;
if the connection is normal, resetting the detection times and waiting for the timer to trigger the next detection, and if the detection fails, adding one to the detection times and waiting for the timer to trigger the next detection;
and if the maximum number of detection times is reached, removing the connection pool of the connection and updating the connection configuration file of the node.
Further, when a certain connection of the node is overtime, a reconnection operation is initiated, and if the maximum reconnection number is reached, the connection is considered to be failed, and the connection is deleted from the connection pool of the node.
Further, the main process of the union link point consensus comprises the following steps:
(1) the client initiates a transaction to any node;
(2) after receiving the transaction request, the node carries out validity verification, generates a prefix after the verification and forwards the prefix to other nodes connected with the node in a connection pool of the node; after receiving the preprepare message, other nodes compare the preprepare message with the message pool of the node, if the message is received for the first time, the message is forwarded to other nodes connected with the node in the connection pool of the node, and so on, thereby realizing the whole network broadcast;
(3) after receiving the preppare, the node carries out validity verification, generates the prepare after the verification and forwards the prepare to other nodes connected with the node in a connection pool of the node; after receiving the prefix message, other nodes compare the prefix message with the message pool of the node, if the message is received for the first time, the message is forwarded to other nodes connected with the node in the connection pool of the node, and so on, thereby realizing the whole network broadcast;
(4) if the node receives more than 2f prepare messages and f is the number of the fault-tolerant nodes, a commit message is generated and forwarded to other nodes connected with the node in the connection pool of the node, after the other nodes receive the commit message, the commit message is compared with the message pool of the node, if the commit message is received for the first time, the commit message is forwarded to other nodes connected with the node in the connection pool of the node, and the like, so that the whole network broadcasting is realized;
(5) if the node receives more than 2f commit messages, the node considers that the consensus is achieved in the whole network, then the transaction is executed, a block is generated, and the execution result is returned to the client.
Further, when the alliance chain network is upgraded, the network configuration of the corresponding node needs to be updated, the node updates the corresponding network connection pool in real time for message forwarding, and the block is pulled from the connected node.
Further, if the messages in the node message pool are processed and the messages generate blocks, the messages which are considered to have reached the whole network consensus are removed from the message pool, and therefore the messages in the message pool are all the messages which are newly received and are not in the consensus waiting for processing.
The invention has the beneficial effects that: the alliance chain networking method based on the BFT consensus algorithm optimizes the full-connection network of the BFT consensus into a mixed connection, reduces the complexity of O (N ^2) of the connection to O (N), ensures the broadcast of the message in the whole network, performs related transformation on the traditional BFT consensus process and realizes the correctness of the BFT consensus algorithm in the networking mode; the efficiency of the BFT consensus algorithm is guaranteed, and meanwhile the block chain can be applied to a larger-scale scene.
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 introduced below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to these drawings without creative efforts.
FIG. 1 is a schematic diagram of P2P network networking;
FIG. 2 is a schematic diagram of a federation chain networking of the present invention;
FIG. 3 is a connection flow diagram for a new node joining a federation chain;
FIG. 4 is a schematic diagram of a message forwarding mechanism;
FIG. 5 is a block link point consensus flow chart;
fig. 6 is a block chain network expansion diagram.
Detailed Description
In order to make the aforementioned objects, features and advantages of the present invention comprehensible, embodiments accompanied with figures are described in detail below.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention, but the present invention may be practiced in other ways than those specifically described and will be readily apparent to those of ordinary skill in the art without departing from the spirit of the present invention, and therefore the present invention is not limited to the specific embodiments disclosed below.
The invention keeps the original three-stage consensus on the basis of the PBFT consensus algorithm. To achieve the consensus requirement, messages need to be broadcast to the various nodes. It is specifically stated that, unlike the conventional accounting node, the conventional accounting node does not participate in consensus, and both the security and the decentralization degree are low, and the blockchain nodes of the present invention participate in consensus, so that the high security and the decentralization blockchain characteristics are ensured, and the performance is not significantly reduced with the increase of scale. The consensus algorithm is chosen for Byzantine Fault Tolerance (BFT) because such consensus algorithms are relatively efficient and additionally tolerant of byzantine node and failed node errors.
The network structure of the alliance-link networking of the invention is shown in fig. 2, and the overall design is as follows:
when a blockchain network node is networked, a connection node is configured through a configuration file, so that the node is prevented from becoming an island in a network due to a network connection problem, and therefore the following is specified in design:
1. the node connection number is more than or equal to 2, namely, any node is ensured to be connected with at least two other nodes;
2. the connected nodes can be dynamically updated through configuration files.
Each node has a connection pool and a message pool.
The networking method is mainly used for establishing the alliance link network. Unlike the network construction of ether houses or bitcoin, the discovery of their nodes mainly seeks other nodes close to the target node, then tries to connect and updates the own node connection list. Aiming at the characteristics of the alliance chain, the invention designs a configuration file to establish connection. Because the alliance chain is different from the public chain, the etherhouse and the bitcoin are public chains, and the public chain is an unlicensed chain, that is, any node can join the blockchain network, and then the node can be connected with any node when joining the network. A federation chain is a permissive chain, that is to say the connection of nodes, which nodes are connected to require permission to be audited. The invention can manage the connection of the network nodes of the block chain in a configuration file mode so as to achieve the management and control of the alliance chain network.
The new node can be a common node or a non-common node, and the role of the node can be specified through configuration. When a new node joins a federation chain, a target node needing to be connected is obtained through a target node list of a configuration file, then a connection operation is initiated, and the identities of the other sides are mutually verified through an interactive message with a certificate signature, so that an admission authorization mechanism of a network node of the federation chain is realized, as shown in fig. 3, the admission authorization mechanism specifically comprises the following steps:
(1) starting a new node;
(2) the new node initiates link operation to the target node according to the configuration file;
(3) starting a timer for triggering a plurality of attempted connections;
(4) creating a connection coroutine for processing connection interaction with a target node;
(5) initiating a handshake operation to apply for connection resources;
(6) generating a handshake message IdentityMsg with a certificate signature;
(7) sending IdentityMsg;
(8) waiting for a return message of the target node;
(9) the target node performs signature verification on the received IdentityMsg, if the IdentityMsg passes the signature verification, an Rsp message with a certificate signature is sent, and otherwise, an Rsp message refusing to connect is sent;
(10) the new node analyzes the received Rsp message, and if the Rsp message is a connection rejection message, the new node directly returns the Rsp message; if the message is an Rsp message with a signature, executing the step (11) to verify the signature;
(11) if the certificate is not verified, sending a connection refusing message to the target node; if the certificate passes the verification, sending a verification passing message; waiting for the return message of the target node;
(12) the target node analyzes the received message, and if the message is a connection refusal message, the message is directly returned; if the verification passes, sending a connection completion message, and updating the connection pool of the user;
(13) and if the new node receives the connection completion message of the target node, updating the connection pool of the new node to complete connection.
The security of the node connection is ensured by the way of handshake confirmation and certificate verification, and the identity information (certificate) of the other party is mutually verified.
In the embodiment of the application, when a network node of the federation chain is changed, for example, a certain connection of the node is abnormal or a node is newly added, the connection pool and the configuration file of the node are updated, a network structure of the federation chain is constructed through the configuration file of the node and the connection pool of the node, and routing and positioning of related resources can be performed quickly.
In the embodiment of the present application, the heartbeat mechanism is specifically as follows:
when the node completes the connection establishment, a heartbeat detection coroutine is started, and the connection condition of the connection pool is detected at regular time. If the connection is normal, clearing the detection times, waiting for the timer to trigger the next detection, and if the detection fails, adding one to the detection times, and waiting for the timer to trigger the next detection. If the maximum number of detection times is reached (namely the number of abnormal connections reaches the maximum value), the connection is removed from the connection pool, and the connection configuration file of the node is updated, so that the connection of the connection pool and the target node of the configuration file is ensured to be normally communicated.
In the embodiment of the present application, the network recovery mechanism is specifically as follows:
when a certain connection of the nodes is overtime, the connection number of the nodes is more than or equal to 2 due to scheme design, and the work is not influenced at this time; however, for the reliability of the network, when a certain connection is overtime, reconnection operation is initiated, and if the maximum reconnection number is reached, the connection is considered to be failed, the connection is deleted from the connection pool of the node, and the update of the connection pool is completed.
In the embodiment of the present application, the message forwarding mechanism is shown in fig. 4, and specifically as follows:
the node receives the message and compares the message with the message in the message pool, if the message is received, the message is directly returned, if the message is a new message, the new message is put into the message pool to be processed, and the new message is broadcasted to other nodes connected with the node, so that the purpose that the message is broadcasted to the nodes of the whole network is realized.
In the embodiment of the present application, the consensus process is shown in fig. 5, and specifically as follows:
(1) the client initiates a transaction to any node;
(2) after receiving the transaction request, the node performs validity verification (such as certificate verification, message digest verification and the like), generates preprepare after verification and forwards the preprepare to other nodes connected with the node in a connection pool of the node; after receiving the preprepare message, other nodes compare the preprepare message with the message pool of the node, if the message is received for the first time, the message is forwarded to other nodes connected with the node in the connection pool of the node, and so on, thereby realizing the whole network broadcast;
(3) after receiving the preppare, the node carries out validity verification, generates the prepare after the verification and forwards the prepare to other nodes connected with the node in a connection pool of the node; after receiving the prefix message, other nodes compare the prefix message with the message pool of the node, if the message is received for the first time, the message is forwarded to other nodes connected with the node in the connection pool of the node, and so on, thereby realizing the whole network broadcast;
(4) if the node receives more than 2f prepare messages (f is the number of fault-tolerant nodes, n is more than 3f +1, n is the number of block chain link points), a commit message is generated and forwarded to other nodes connected with the node in the connection pool of the node, after the other nodes receive the commit message, the commit message is compared with the message pool of the node, if the commit message is received for the first time, the commit message is forwarded to other nodes connected with the node in the connection pool of the node, and the rest is done in the same way, so that the whole network broadcasting is realized;
(5) if the node receives more than 2f commit messages, the node considers that the consensus is achieved in the whole network, then the transaction is executed, a block is generated, and the execution result is returned to the client.
In the embodiment of the present application, the block chain network is expanded as shown in fig. 6, specifically as follows:
when the block chain network is upgraded, the network configuration of the corresponding node needs to be updated, the node updates the corresponding network connection pool in real time for message forwarding, and the block is pulled from the connected node.
The foregoing is only a preferred embodiment of the present invention, and although the present invention has been disclosed in the preferred embodiments, it is not intended to limit the present invention. Those skilled in the art can make numerous possible variations and modifications to the present teachings, or modify equivalent embodiments to equivalent variations, without departing from the scope of the present teachings, using the methods and techniques disclosed above. Therefore, any simple modification, equivalent change and modification made to the above embodiments according to the technical essence of the present invention are still within the scope of the protection of the technical solution of the present invention, unless the contents of the technical solution of the present invention are departed.
Claims (8)
1. A BFT consensus-based federation chain networking method is characterized in that the method comprises the following steps:
when the alliance link node is networked, the connection node is configured through the configuration file, and the following conditions are met: the node connection number is more than or equal to 2, namely, any node is ensured to be connected with at least two other nodes; the connected nodes can be dynamically updated through the configuration files;
each alliance link node is provided with a connection pool and a message pool;
when a new node joins a alliance chain, a target node needing to be connected is obtained through a target node list of a configuration file, then connection operation is initiated, and the identities of the other sides are mutually verified through an interactive message with a certificate signature, so that an access authorization mechanism of network nodes of the alliance chain is realized;
when the nodes of the alliance chain network are changed, updating the connection pool and the configuration file of the nodes;
when receiving the message, the node compares the message with the message in the message pool, if the message is received, the message is directly returned, if the message is a new message, the new message is put into the message pool to be processed, and the new message is broadcasted to other nodes connected with the new message, so that the message is broadcasted to the nodes of the whole network.
2. The BFT consensus-based federation chain networking method of claim 1, wherein the new node may be a consensus node or a non-consensus node, and the role of the node is specified by configuration.
3. The BFT consensus-based federation chain networking method of claim 1, wherein when a new node joins a federation chain, the connection steps are as follows:
starting a new node, and initiating link operation to a target node according to a configuration file; starting a timer for triggering a plurality of attempted connections; creating a connection coroutine for processing connection interaction with a target node; initiating a handshake operation to apply for connection resources; generating a handshake message IdentityMsg with a certificate signature, sending the IdentityMsg, and waiting for a return message of a target node;
the target node carries out signature verification on the received IdentityMsg, if the verification is passed, an Rsp message with a certificate signature is sent, and otherwise, an Rsp message refusing connection is sent;
the new node analyzes the received Rsp message, and if the Rsp message is a connection rejection message, the new node directly returns the message; if the message is the Rsp message with the signature, performing signature verification, if the certificate verification fails, sending a connection refusing message to the target node, and if the certificate verification passes, sending a verification passing message;
the target node analyzes the received message, and if the message is a connection refusal message, the message is directly returned; if the verification passes, sending a connection completion message, and updating the connection pool of the user;
and after receiving the connection completion message of the target node, the new node updates the connection pool of the new node to complete the connection.
4. The method for networking an alliance chain based on BFT consensus as claimed in claim 1, wherein when a node completes establishing a connection, a heartbeat detection protocol is started to detect the connection condition of a connection pool at regular time;
if the connection is normal, resetting the detection times and waiting for the timer to trigger the next detection, and if the detection fails, adding one to the detection times and waiting for the timer to trigger the next detection;
and if the maximum number of detection times is reached, removing the connection pool of the connection and updating the connection configuration file of the node.
5. A method for federation chain networking based on BFT consensus as claimed in claim 1, wherein when a connection at a node times out, a reconnect operation is initiated, and if the maximum number of reconnections is reached, the connection is considered to have failed, and the connection is removed from the connection pool at the node.
6. The BFT consensus-based federation chain networking method of claim 1, wherein the main flow of federation chain nodes reaching consensus comprises the steps of:
(1) the client initiates a transaction to any node;
(2) after receiving the transaction request, the node carries out validity verification, generates a prefix message after verification and forwards the prefix message to other nodes connected with the node in a connection pool of the node; after receiving the preprepare message, other nodes compare the preprepare message with the message pool of the node, if the message is received for the first time, the message is forwarded to other nodes connected with the node in the connection pool of the node, and so on, thereby realizing the whole network broadcast;
(3) after receiving the prefix message, the node carries out validity verification, generates the prefix message after the validity verification and forwards the prefix message to other nodes connected with the node in a connection pool of the node; after receiving the prefix message, other nodes compare the prefix message with the message pool of the node, if the message is received for the first time, the message is forwarded to other nodes connected with the node in the connection pool of the node, and so on, thereby realizing the whole network broadcast;
(4) if the node receives more than 2f prepare messages and f is the number of the fault-tolerant nodes, a commit message is generated and forwarded to other nodes connected with the node in the connection pool of the node, after the other nodes receive the commit message, the commit message is compared with the message pool of the node, if the commit message is received for the first time, the commit message is forwarded to other nodes connected with the node in the connection pool of the node, and the like, so that the whole network broadcasting is realized;
(5) if the node receives more than 2f commit messages, the node considers that the consensus is achieved in the whole network, then the transaction is executed, a block is generated, and the execution result is returned to the client.
7. The BFT consensus-based federation chain networking method of claim 1, wherein when a federation chain network is upgraded, the network configuration of the corresponding node needs to be updated, the node updates the corresponding network connection pool in real time for message forwarding, and pulls blocks from the connected nodes.
8. A method for federation chain networking based on BFT consensus as claimed in claim 1, wherein if a message in the node message pool has been processed and the message has generated a chunk, then considering that the full network consensus has been reached, and removing the message with the chunk generated from the message pool, thereby ensuring that the messages in the message pool are all newly received pending messages that do not reach the consensus.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010264747.3A CN111586102B (en) | 2020-04-07 | 2020-04-07 | BFT consensus-based alliance chain networking method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010264747.3A CN111586102B (en) | 2020-04-07 | 2020-04-07 | BFT consensus-based alliance chain networking method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111586102A CN111586102A (en) | 2020-08-25 |
| CN111586102B true CN111586102B (en) | 2021-05-18 |
Family
ID=72112985
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010264747.3A Active CN111586102B (en) | 2020-04-07 | 2020-04-07 | BFT consensus-based alliance chain networking method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111586102B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112508562B (en) * | 2020-12-01 | 2024-04-19 | 浙商银行股份有限公司 | Blockchain open transaction multi-level consensus method, equipment and storage medium |
| CN112564960B (en) * | 2020-12-01 | 2022-05-13 | 浙商银行股份有限公司 | Elastic adjustment consensus method and device based on block link point centrality |
| CN113783947A (en) * | 2021-08-26 | 2021-12-10 | 浙商银行股份有限公司 | Adaptive block link point fault tolerance improving method, equipment and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10326802B1 (en) * | 2018-12-04 | 2019-06-18 | Xage Security, Inc. | Centrally managing data for orchestrating and managing user accounts and access control and security policies remotely across multiple devices |
| CN110035059A (en) * | 2019-03-05 | 2019-07-19 | 深圳前海微众银行股份有限公司 | A kind of building of block chain and group partition method and device |
| CN110033373A (en) * | 2019-03-12 | 2019-07-19 | 平安科技（深圳）有限公司 | Device, method and the storage medium endorsed in block chain |
| CN110569309A (en) * | 2019-09-17 | 2019-12-13 | 上海保险交易所股份有限公司 | Apparatus, method, system, and medium for implementing blockchains |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107146087A (en) * | 2017-04-11 | 2017-09-08 | 广东网金控股股份有限公司 | A kind of quick common recognition bookkeeping methods and system based on block chain alliance chain |
-
2020
- 2020-04-07 CN CN202010264747.3A patent/CN111586102B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10326802B1 (en) * | 2018-12-04 | 2019-06-18 | Xage Security, Inc. | Centrally managing data for orchestrating and managing user accounts and access control and security policies remotely across multiple devices |
| CN110035059A (en) * | 2019-03-05 | 2019-07-19 | 深圳前海微众银行股份有限公司 | A kind of building of block chain and group partition method and device |
| CN110033373A (en) * | 2019-03-12 | 2019-07-19 | 平安科技（深圳）有限公司 | Device, method and the storage medium endorsed in block chain |
| CN110569309A (en) * | 2019-09-17 | 2019-12-13 | 上海保险交易所股份有限公司 | Apparatus, method, system, and medium for implementing blockchains |
Non-Patent Citations (2)
| Title |
|---|
| 基于动态授权的拜占庭容错共识算法的区块链性能改进研究;刘肖飞;《中国优秀硕士学位论文全文数据库 信息科技辑》;20180115(第1期);全文 * |
| 基于联盟链的多链式区块链共识性能研究;孙一蓬;《中国优秀硕士学位论文全文数据库 信息科技辑》;20200115(第1期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111586102A (en) | 2020-08-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111586102B (en) | BFT consensus-based alliance chain networking method | |
| Lei et al. | Reputation-based byzantine fault-tolerance for consortium blockchain | |
| US20210256007A1 (en) | Blockchain system and blockchain transaction data processing method based on ethereum | |
| JP2022159468A (en) | Computer-implemented system and method for updating network's perception of network's topology | |
| Koo et al. | Reliable broadcast in radio networks: The bounded collision case | |
| Jiang et al. | High performance and scalable byzantine fault tolerance | |
| CN111582843A (en) | Block chain privacy transaction method based on aggregated signature | |
| CN109617994A (en) | A kind of method and system positioning block chain interior joint position | |
| CN113746858A (en) | Cross-chain communication method based on verifiable random function | |
| CN111464632B (en) | Block chain cross-chain forwarding method and block chain link point | |
| CN110971702A (en) | Service calling method and device, computer equipment and storage medium | |
| JP2024517445A (en) | Blockchain-based data processing method, data processing device, computer device, and computer program | |
| CN112910663A (en) | Method, device, equipment and storage medium for message broadcasting and terminal registration | |
| CN116455685A (en) | PBFT improved consensus method under broadcast network | |
| CN115052006A (en) | Data synchronization method and system based on leader node | |
| CN111818152B (en) | Leader election consensus method based on distributed network | |
| CN115842676A (en) | Cross-chain transaction method, system and medium based on notary group | |
| CN112398934B (en) | Trusting broadcasting method based on block chain | |
| Tang et al. | Excellent practical byzantine fault tolerance | |
| CN116846888A (en) | Consensus processing method, device, equipment and storage medium of block chain network | |
| CN112242925B (en) | Safety management method and equipment | |
| Wang et al. | AC: an NDN-based blockchain network with erasure coding | |
| CN110995413B (en) | Alliance chain consensus node management method for preventing pseudo node attack | |
| Tan et al. | A novel dynamic practical byzantine fault tolerance protocol based on node grouping | |
| CN111682961B (en) | Method for eliminating low-bandwidth nodes in I2P network, computer readable storage medium and I2P network |
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 | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20220526 Address after: No. 1788, Hongning Road, Xiaoshan District, Hangzhou, Zhejiang 311200 Patentee after: CHINA ZHESHANG BANK Co.,Ltd. Patentee after: Yiqiyin (Hangzhou) Technology Co., Ltd Address before: No. 1788, Hongning Road, Xiaoshan District, Hangzhou, Zhejiang 311200 Patentee before: CHINA ZHESHANG BANK Co.,Ltd. |
|
| TR01 | Transfer of patent right |