CN111539726B - Block chain consensus system and method - Google Patents
Block chain consensus system and method Download PDFInfo
- Publication number
- CN111539726B CN111539726B CN202010310684.0A CN202010310684A CN111539726B CN 111539726 B CN111539726 B CN 111539726B CN 202010310684 A CN202010310684 A CN 202010310684A CN 111539726 B CN111539726 B CN 111539726B
- Authority
- CN
- China
- Prior art keywords
- consensus
- node
- nodes
- network
- transaction
- 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
- 238000000034 method Methods 0.000 title claims abstract description 51
- 238000012795 verification Methods 0.000 claims abstract description 44
- 238000012545 processing Methods 0.000 claims abstract description 33
- 238000002360 preparation method Methods 0.000 claims description 63
- 230000008569 process Effects 0.000 claims description 24
- 238000001914 filtration Methods 0.000 claims description 8
- 230000003211 malignant effect Effects 0.000 claims description 3
- 238000003860 storage Methods 0.000 description 27
- 230000006870 function Effects 0.000 description 15
- 238000004590 computer program Methods 0.000 description 13
- 238000010586 diagram Methods 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 9
- 238000004891 communication Methods 0.000 description 8
- 230000004044 response Effects 0.000 description 5
- 239000000872 buffer Substances 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 239000003795 chemical substances by application Substances 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 238000012856 packing Methods 0.000 description 2
- 238000013473 artificial intelligence Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
Classifications
-
- 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/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3827—Use of message hashing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
- H04L41/044—Network management architectures or arrangements comprising hierarchical management structures
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Accounting & Taxation (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
- Hardware Redundancy (AREA)
Abstract
A blockchain consensus system and method, the system including a consensus node and a proxy node; broadcasting a transaction request received by the consensus node to other consensus nodes and proxy nodes in the sub-consensus network to perform verification processing; receiving transaction requests broadcast by other consensus nodes or transaction requests provided by proxy nodes, comparing and verifying transaction results with the consensus results fed back by the proxy nodes, and linking the transaction results or the consensus results according to the verification results; the proxy node consensus the transaction request to other proxy nodes in the main network through a Bayesian algorithm according to the transaction request broadcast by the sub-consensus network, or obtains the transaction request consensus by other proxy nodes in the main network, and provides the transaction request to the sub-consensus network for processing by the consensus node; and obtaining the consensus result of the transaction request in the main network, and providing the consensus result to the sub-consensus network for comparison by the consensus nodes.
Description
Technical Field
The invention relates to the technical field of block chains and the field of consensus algorithms, in particular to a block chain consensus system and a block chain consensus method.
Background
The blockchain technology is a technical scheme for collectively maintaining one or more reliable data in an decentralization mode, has the characteristics of decentralization, tamper resistance, high expandability and the like, and is gradually an emerging technology which has great influence on the world after technologies such as big data, cloud computing, artificial intelligence, virtual reality and the like.
The blockchain core technology is mainly a point-to-point distributed technology, an asymmetric encryption technology, a hash algorithm and a consensus mechanism. With the gradual popularization of the blockchain technology, a consensus mechanism has become a key bottleneck for the promotion of a blockchain system.
The current consensus algorithm mainly comprises PoW (workload proof), poS (rights and interests proof), PBFT (bayer fault tolerance algorithm), RAFT and the like. As known from practice in industry, a single consensus algorithm has various problems, although PoW has obvious advantages in fault tolerance and the number of participating nodes, a large number of hash functions need to be calculated and consensus is achieved, and performance and time loss are large; the PoS has the problem of 'rich and luxury control', the PBFT algorithm has slightly improved performance relatively, malicious nodes can be easily found in the running process, but the performance is greatly reduced when the number of the nodes exceeds a certain scale. How to solve the relationship among the node scale, the performance and the fault tolerance through the consensus algorithm becomes a problem to be solved urgently in the current blockchain technology and the consensus algorithm development.
Through the preliminary knowledge of the application mode of the industry consensus algorithm, when a blockchain network applies a certain consensus algorithm, no matter how many nodes exist in the blockchain network, all nodes need to completely go through the flow of the consensus algorithm in one or more times, and the whole blockchain network can achieve the theoretical final consensus.
Disclosure of Invention
The invention aims to provide a block chain consensus system and a block chain consensus method, wherein a consensus algorithm is applied to local nodes of a block chain network in a framework layering mode so as to realize the effect of hierarchical consensus of the block chain network, and the block chain performance and throughput of the block chain can be improved to a certain extent.
In order to achieve the above object, the present invention provides a blockchain consensus system, the system includes a plurality of blockchain nodes, the blockchain nodes include a plurality of consensus nodes and a plurality of proxy nodes; wherein, a plurality of proxy nodes form a main network, and a plurality of consensus nodes and one proxy node form a sub-consensus network; the consensus node is used for receiving a transaction request, broadcasting the transaction request to other consensus nodes in the sub-consensus network and the proxy node for verification processing; and receiving transaction requests broadcast by other consensus nodes in the sub-consensus network or transaction requests provided by agent nodes, generating preparation messages according to the transaction requests and broadcasting the preparation messages to the other consensus nodes in the sub-consensus network, and processing the transaction requests to generate transaction results when the number of the received preparation messages is higher than a preset threshold; comparing and verifying the transaction result with the consensus result fed back by the proxy node, and linking the transaction result or the consensus result according to the verification result; the proxy node is used for consensus the transaction request to other proxy nodes in the main network through a Bayesian algorithm according to the transaction request broadcast by the sub-consensus network; obtaining a consensus result of the transaction request in the main network, and providing the consensus result to a sub-consensus network for comparison by the consensus node; the transaction request which is commonly recognized by other proxy nodes in the main network is obtained through a Bayesian algorithm, and the transaction request is provided to a sub-consensus network where the transaction request is located for processing by the consensus node; and obtaining a consensus result of the transaction request in the main network, and providing the consensus result to a sub-consensus network where the consensus result is located for comparison by the consensus node.
In the above blockchain consensus system, preferably, the blockchain node includes a transceiver request module, a broadcast request module, a transaction execution module, and a consensus module; the receiving and transmitting request module is used for receiving a transaction request uploaded by an external application; or, receiving transaction requests broadcast by other consensus nodes in the sub-consensus network or transaction requests provided by proxy nodes; the broadcasting request module is used for broadcasting the transaction request to the corresponding consensus node and the proxy node according to the IP addresses of other consensus nodes and the proxy node in the sub-consensus network; the transaction execution module is used for processing the transaction request to generate a transaction result; comparing and verifying the transaction result with the consensus result fed back by the proxy node, and linking the transaction result or the consensus result according to the verification result; the consensus module is used for splicing message messages in the consensus process of the Bayesian-preemptive consensus algorithm, and generating a preparation message according to the consistency of the message messages.
In the above blockchain consensus system, preferably, the blockchain node further includes a filtering module and a statistics module; the filtering module is used for obtaining the IP addresses of other consensus nodes and the proxy node according to the routing table of the sub-consensus network; the statistics module is used for comparing the number of the received preparation messages with a preset threshold value, and when the number of the received preparation messages is higher than the preset threshold value, the transaction execution module is informed to process the transaction request to generate a transaction result.
In the above blockchain consensus system, preferably, the blockchain node further includes a node ordering module and a node role module; the node ordering module is used for adjusting the identity information of the consensus node and the proxy node in the block chain link point according to a preset ordering rule, and updating the identity role of the current block chain node into the consensus node or the proxy node according to the adjusted identity information; the node role module is used for recording the identity roles of the current blockchain nodes.
The invention also provides a block chain consensus method, comprising the following steps: dividing the blockchain nodes into consensus nodes and proxy nodes through preset rules, wherein a plurality of proxy nodes form a main network, and a plurality of consensus nodes and one proxy node form a sub-consensus network; broadcasting the transaction request received by the consensus node to other consensus nodes and the proxy node in the sub-consensus network to perform verification processing; the other consensus nodes in the sub-consensus network where the consensus node is located generate preparation information according to the transaction request and broadcast the preparation information to the other consensus nodes in the sub-consensus network, and when the number of the received preparation information is higher than a preset threshold value, the transaction request is processed to generate a transaction result; obtaining a consensus result of the transaction request in the main network through a proxy node, and providing the consensus result to a sub-consensus network where the consensus result is located for comparison by the consensus node; and the consensus node compares and verifies the transaction result with the consensus result fed back by the proxy node, and links the transaction result or the consensus result into a chain according to the verification result.
In the above blockchain consensus method, preferably, broadcasting the transaction request to other consensus nodes in the sub-consensus network and the proxy node to perform verification processing includes: the consensus node obtains the IP addresses of other consensus nodes and the proxy node according to the routing table of the sub-consensus network; and broadcasting the transaction request to other consensus nodes and the proxy nodes in the sub-consensus network to perform verification processing through the IP address.
In the above blockchain consensus method, preferably, obtaining, by a proxy node, a consensus result of the transaction request in the primary network includes: the proxy node commonly recognizes the transaction request to other proxy nodes in the main network through a Bayesian algorithm according to the transaction request broadcast by the sub-consensus network; and generating a consensus result according to the consensus situation of the transaction request in the main network.
In the above blockchain consensus method, preferably, obtaining the consensus result of the transaction request in the primary network further includes: after receiving the transaction request, other proxy nodes of the main network where the proxy nodes are located verify the transaction request, and broadcast verification results to other proxy nodes of the main network; and receiving verification results broadcast by other proxy nodes, comparing the verification results with the self verification results, and broadcasting the transaction request to all consensus nodes in the sub-consensus network for processing when the number of the consistent comparison results is higher than a preset threshold value.
In the above blockchain consensus method, preferably, the predetermined threshold is 2f+1 nodes in a sub-consensus network where the consensus node is located or a main network where the proxy node is located; wherein f is the upper limit number of malignant nodes or the number of fault nodes in the sub-consensus network or the main network.
The invention also provides an electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the above method when executing the computer program.
The present invention also provides a computer readable storage medium storing a computer program for executing the above method.
The beneficial technical effects of the invention are as follows: the whole network is divided into a plurality of sub-consensus networks and a core main network in a hierarchical mode, and under the architecture, the number of times that a plurality of nodes need to communicate due to consensus is reduced; colleagues relatively improve throughput of the whole network response; in addition, in the consensus process, each node of the sub-consensus network can execute corresponding transaction in advance, and the transaction result is used as a verification standard, so that the node consensus process and the transaction executing process are parallel, and the performance of the whole network is improved to a certain extent.
Drawings
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate and together with the description serve to explain the invention. In the drawings:
FIG. 1 is a block chain consensus system according to an embodiment of the present invention;
FIG. 2 is a schematic diagram of a PBFT three-stage consensus process according to an embodiment of the present invention;
FIG. 3 is a schematic block chain node structure according to one embodiment of the present invention;
FIG. 4 is a flowchart illustrating a block chain consensus method according to an embodiment of the present invention;
FIG. 5 is a schematic diagram of a transaction flow for receiving an external request by a consensus node according to an embodiment of the present invention;
FIG. 6 is a flow chart of a proxy node receiving an external request transaction according to an embodiment of the present invention;
fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the invention.
Detailed Description
The following will describe embodiments of the present invention in detail with reference to the drawings and examples, thereby solving the technical problems by applying technical means to the present invention, and realizing the technical effects can be fully understood and implemented accordingly. It should be noted that, as long as no conflict is formed, each embodiment of the present invention and each feature of each embodiment may be combined with each other, and the formed technical solutions are all within the protection scope of the present invention.
Additionally, the steps illustrated in the flowcharts of the figures may be performed in a computer system such as a set of computer executable instructions, and although a logical order is illustrated in the flowcharts, in some cases the steps illustrated or described may be performed in an order other than that herein.
Referring to fig. 1, the system for block chain consensus provided by the present invention includes a plurality of block chain nodes, wherein the block chain nodes include a plurality of consensus nodes and a plurality of proxy nodes; wherein, a plurality of proxy nodes form a main network, and a plurality of consensus nodes and one proxy node form a sub-consensus network; the consensus node is used for receiving a transaction request, broadcasting the transaction request to other consensus nodes in the sub-consensus network and the proxy node for verification processing; and receiving transaction requests broadcast by other consensus nodes in the sub-consensus network or transaction requests provided by agent nodes, generating preparation messages according to the transaction requests and broadcasting the preparation messages to the other consensus nodes in the sub-consensus network, and processing the transaction requests to generate transaction results when the number of the received preparation messages is higher than a preset threshold; comparing and verifying the transaction result with the consensus result fed back by the proxy node, and linking the transaction result or the consensus result according to the verification result; the proxy node is used for consensus the transaction request to other proxy nodes in the main network through a Bayesian PBFT algorithm according to the transaction request broadcast by the sub-consensus network; obtaining a consensus result of the transaction request in the main network, and providing the consensus result to a sub-consensus network for comparison by the consensus node; the transaction request which is commonly recognized by other proxy nodes in the main network is obtained through a Bayesian algorithm, and the transaction request is provided to a sub-consensus network where the transaction request is located for processing by the consensus node; and obtaining a consensus result of the transaction request in the main network, and providing the consensus result to a sub-consensus network where the consensus result is located for comparison by the consensus node. Thus, under such an architecture, the number of times that multiple nodes need to communicate due to consensus is reduced. If there are 16 nodes in the whole network, the normal PBFT consensus flow nodes need to communicate with each other at least 363 times (11 x 3), and in accordance with such an architecture as described above, the number of times the nodes of the PBFT consensus process communicate with each other the sum is at least 36 times (3 x 3+3 x 3). The communication times are reduced, the response time of the whole network to one transaction is reduced, and the throughput of the whole network response is relatively improved. In addition, in the consensus process, each node of the sub-consensus network can execute corresponding transaction in advance, and the transaction result is used as a verification standard, so that the node consensus process and the transaction executing process are parallel, and the performance of the whole network is improved to a certain extent.
In the above embodiment, the DPOS consensus algorithm and the PBFT algorithm are combined, that is, during the operation of the system, the system will randomly designate a certain number of proxy nodes in all nodes, where the number of proxy nodes is equal to the number-1 of sub-consensus networks in the current network. The system will have a core main network, the core main network is composed of selected proxy nodes, mainly responsible for the most important consensus flow, while other sub-consensus networks acquire the consensus result in the core main network through the proxy nodes, and each sub-consensus network starts a new round of consensus flow with the proxy nodes, and the whole network further achieves comprehensive consensus as each sub-consensus network successfully completes the respective consensus flow. The system reselects the proxy node in each period, and the members of the sub-consensus network where the proxy node is located are different, so that the system further avoids the occurrence of 'dominant luxury' or 'independent nodes'. Meanwhile, the above embodiment divides the PBFT algorithm consensus process into three phases: the pre-path phase, the per path phase, the commit phase are acknowledged if and only if most of the three phases (2f+1 nodes, f representing the number of bad nodes or failed nodes that the network can tolerate) agree on a transaction. The PBFT algorithm can discover fault nodes and dislike nodes to a certain extent through three-stage consensus, but as the number of nodes increases, the cost of the three-stage consensus also increases. In this way, the tasks of three phases in the PBFT algorithm are distributed to the core main network and each sub-consensus network, the core main network is responsible for completing the complete three-phase consensus of the PBFT algorithm, the nodes in each sub-consensus network are mainly responsible for executing the received transaction, the transaction result is compared with the core main network consensus result, and if the transaction result is consistent, each sub-consensus network node can link the corresponding transaction result; if the result is inconsistent, after the result of the total network consensus is stable, each sub-consensus network node uses the consensus result as a final result to enter a chain.
In actual operation, the three-stage flow of the PBFT algorithm is shown in FIG. 2, and mainly comprises a pre-preparation stage, a preparation stage and a commit stage. Under the PBFT algorithm mechanism, the whole network node selects a master node (Leader), the new area block is responsible for generation by the master node, and the backup node can determine whether the current master node has a change or not through a view number. In one view, one is the primary node and the rest are all called backup nodes.
In the pre-preparation stage, each node broadcasts the transaction sent by the client to the whole network, and the master node 0 collects a plurality of transactions which need to be placed in a new block from the network, sorts the transactions, places the transactions into a list and broadcasts the transactions to other backup nodes. Because the PRE-preparation message plays a role in proving in the consensus process, proving that a certain request is processed at the master node 0, the format of the preparation message is < < PRE-preparation, v, n, d >, m > and v represents the view number, m is the request information sent by the client, d is the abstract of the request message m, and generally, the request of the client is not contained in the PRE-preparation message, but in the system, in order to forward or broadcast the corresponding request, certain request data is stored in the PRE-preparation message.
In the "preparation" stage, after each node receives the transaction list, the transactions are simulated and executed according to the ordering. After all the transactions are executed, the backup node calculates a hash abstract of the new block based on the transaction result and broadcasts a preparation message to other nodes. And waiting for all nodes to broadcast the preparation messages from 2f different copy nodes, determining the consistency of message digest m, message sequence number n, view number v and own preparation messages in the received preparation messages, and entering a commit stage by the whole network.
In the "commit" phase, when each node receives the preparation messages sent by 2f different nodes, and the message abstract m, the message sequence number n, the view number v are consistent with the self-generated preparation messages in the preparation messages, the node broadcasts a commit message to the whole network. And receiving consistent commit messages from f+1 different copies by all nodes, and executing all requests by all nodes of the whole network in a normal sequence.
Referring to fig. 3 again, in an embodiment of the present invention, the blockchain node includes a transceiver request module 11, a broadcast request module 12, a transaction execution module 13, and a consensus module 16; the receiving and transmitting request module is used for receiving a transaction request uploaded by an external application; or, receiving transaction requests broadcast by other consensus nodes in the sub-consensus network or transaction requests provided by proxy nodes; the broadcasting request module is used for broadcasting the transaction request to the corresponding consensus node and the proxy node according to the IP addresses of other consensus nodes and the proxy node in the sub-consensus network; the transaction execution module is used for processing the transaction request to generate a transaction result; comparing and verifying the transaction result with the consensus result fed back by the proxy node, and linking the transaction result or the consensus result according to the verification result; the consensus module is used for splicing message messages in the consensus process of the Bayesian-preemptive consensus algorithm, and generating a preparation message according to the consistency of the message messages. Further, the blockchain node further comprises a filtering module 14, a statistics module 15, a node ordering module 18 and a node role module 17; the filtering module is used for obtaining the IP addresses of other consensus nodes and the proxy node according to the routing table of the sub-consensus network; the statistics module is used for comparing the number of the received preparation messages with a preset threshold value, and notifying the transaction execution module to process the transaction request to generate a transaction result when the number of the received preparation messages is higher than the preset threshold value; the node ordering module is used for adjusting the identity information of the consensus node and the proxy node in the block chain link point according to a preset ordering rule, and updating the identity role of the current block chain node into the consensus node or the proxy node according to the adjusted identity information; the node role module is used for recording the identity roles of the current blockchain nodes.
Specifically, the receiving-transmitting request module 11 is responsible for receiving all requests sent by an external application system to the blockchain node, extracting data in the requests, converting the data into a sub-consensus network internal broadcast request, and responding to the request; and on the other hand, the method is responsible for receiving requests broadcast by other nodes and verifying or consensus the request result.
The broadcast request module 12 is responsible for sending the broadcast request received by the blockchain node to other nodes of the network where the node is located, the blockchain will first acquire the routing table of the network where the node is located in the storage module 19 of the blockchain node, and the node will send the broadcast request according to the IP addresses of other nodes on the routing table.
The transaction execution module 13 is responsible for executing the requests received by the transceiving request module 11 and storing the execution results using the storage module 19, and for verifying the requests broadcast by other nodes.
The filtering module 14 mainly plays a role in filtering requests in the system node, when the blockchain node receives requests broadcast by other nodes, the blockchain node firstly acquires a routing table of the network in which the blockchain node is located in the storage module 19, and checks whether a sender of the received requests is in the routing table, if the sender is not in the routing table, the blockchain node will not answer the requests.
The statistics module 15 mainly plays a role in the PBFT three-phase consensus of the system, and when the blockchain node receives other nodes pre-preparation messages, preparation messages and commit messages, the blockchain node can count whether the received consistent messages meet the threshold of the PBFT three-phase consensus.
The consensus module 16 is a main module for performing PBFT algorithm consensus of the system, and the consensus module 16 is mainly responsible for splicing message messages in the three-stage process of the PBFT algorithm, verifying consistency of various message messages in the three-stage process, generating a PBFT three-stage consensus result and the like.
The role function 17 represents the role that the node has, a consensus node or a proxy node. The role function module 17 defines the functions performed by the node differently according to the roles of the node.
The node ordering module 18 is mainly used for assisting the system to allocate two roles of the consensus node and the proxy node in each node according to a certain rule and in a certain system period, and stores the roles owned by the nodes by using the storage module 19. The roles of the nodes may change during a certain period, and the functions possessed by the nodes may change accordingly.
The storage module 19 mainly stores the execution results, verification results, consensus results, and roles assigned by the node ordering module 18 in each system cycle for each request.
In summary, as shown in fig. 1, in actual operation, the blockchain consensus system provided by the present invention mainly includes two nodes: a plurality of consensus nodes 1 and a plurality of proxy nodes 2, the plurality of consensus nodes 1 and one proxy node 2 logically form a sub-consensus network 3, and the plurality of proxy nodes 2 form a core main network.
The consensus node 1 is a network node for receiving, executing, forwarding, verifying and storing the transaction in the blockchain network, the consensus node 1 is mainly responsible for receiving and executing external access requests, broadcasting the requests in the corresponding sub-consensus network, verifying the requests of the other consensus node 1 or proxy node 2, and linking the corresponding transaction and transaction result requests.
The proxy node 2 is similar to the consensus node 1, the proxy node 2 can process the request sent by the outside, and plays a role of a whistle in the corresponding sub-consensus network, the proxy node 2 forwards the request received by the sub-consensus network to the core main network where the proxy node 2 is located, and after other proxy nodes 2 in the core main network receive the request broadcast by other proxy nodes 2, each proxy node 2 can broadcast in the respective sub-consensus network, so that each consensus node 1 can execute the corresponding transaction. In the core main network, the proxy node 2 participates in complete PBFT three-stage consensus, broadcasts the consensus result in the core main network to the sub-consensus network where the core main network is located, and determines whether to link the corresponding transaction and the transaction result on the proxy node 2 according to the verification result of each consensus node 1 of the sub-consensus network.
The sub-consensus network 3 is a network which logically consists of a plurality of consensus nodes 1 and a certain proxy node 2 according to a certain rule, each node in the sub-consensus network only broadcasts the received transaction in the sub-consensus network, each consensus node 1 only executes a commit phase in three phases of a PBFT algorithm in the sub-consensus network, and when most nodes (2f+1 nodes, f represents the tolerable number of bad nodes or fault nodes of the network) exist in all the consensus nodes 1 and the contained proxy nodes 2, the sub-consensus network can synchronize the transaction at each node.
The core main network 4 is a network which is formed by logically combining all proxy nodes 2 according to a certain rule, and all nodes in the core main network are the same as the nodes of the sub-consensus network, and only the received transaction is broadcasted in the nodes of the core main network by the nodes. In the core main network, when each proxy node 2 receives the request broadcast by other proxy nodes 2, the proxy node 2 will broadcast the request to the sub-consensus network where the proxy node 2 is located, so that the consensus node 1 will execute the request, and each proxy node 2 in the core main network will completely pass through three phases of the PBFT algorithm, and after all nodes in the core main network agree on the transaction result, each proxy node 2 will broadcast the transaction result in each sub-consensus network where the proxy node 2 is located, and the consensus node 1 in each sub-network will verify the corresponding result.
Referring to fig. 4, the present invention further provides a blockchain consensus method, which includes:
step S401: dividing the blockchain nodes into consensus nodes and proxy nodes through preset rules, wherein a plurality of proxy nodes form a main network, and a plurality of consensus nodes and one proxy node form a sub-consensus network;
step S402: broadcasting the transaction request received by the consensus node to other consensus nodes and the proxy node in the sub-consensus network to perform verification processing;
step S403: the other consensus nodes in the sub-consensus network where the consensus node is located generate preparation information according to the transaction request and broadcast the preparation information to the other consensus nodes in the sub-consensus network, and when the number of the received preparation information is higher than a preset threshold value, the transaction request is processed to generate a transaction result;
step S404: obtaining a consensus result of the transaction request in the main network through a proxy node, and providing the consensus result to a sub-consensus network where the consensus result is located for comparison by the consensus node;
step S405: and the consensus node compares and verifies the transaction result with the consensus result fed back by the proxy node, and links the transaction result or the consensus result into a chain according to the verification result.
In the above embodiment, broadcasting the transaction request to other consensus nodes and the proxy node in the sub-consensus network for verification processing may include: the consensus node obtains the IP addresses of other consensus nodes and the proxy node according to the routing table of the sub-consensus network; and broadcasting the transaction request to other consensus nodes and the proxy nodes in the sub-consensus network to perform verification processing through the IP address.
In one embodiment of the present invention, obtaining, by a proxy node, a consensus result of the transaction request at the primary network includes: the proxy node commonly recognizes the transaction request to other proxy nodes in the main network through a Bayesian algorithm according to the transaction request broadcast by the sub-consensus network; and generating a consensus result according to the consensus situation of the transaction request in the main network. Meanwhile, after receiving the transaction request, other proxy nodes of the main network where the proxy nodes are located verify the transaction request, and broadcast verification results to other proxy nodes of the main network; and receiving verification results broadcast by other proxy nodes, comparing the verification results with the self verification results, and broadcasting the transaction request to all consensus nodes in the sub-consensus network for processing when the number of the consistent comparison results is higher than a preset threshold value.
In the above embodiment, the predetermined threshold is 2f+1 node numbers in a sub-consensus network where the consensus node is located or a main network where the proxy node is located; wherein f is the upper limit number of malignant nodes or the number of fault nodes in the sub-consensus network or the main network.
In order to better understand the above embodiments of the present invention, please refer to fig. 5, in actual operation, a specific implementation flow of the blockchain consensus method is as follows:
step S501: the application system accessing the blockchain sends a request to the consensus node 1 of a certain sub-consensus network, and the consensus node 1 judges whether the request needs to modify the blockchain data, such as the world state, after receiving the request through the receiving and transmitting request module 11. The consensus node 1 converts the request into an internal request and tags the request message with corresponding tags according to whether the request needs to modify the blockchain data. The consensus node 1 uses the storage module 19 to obtain the routing table of the sub-consensus network where the current consensus node 1 is located, and broadcasts corresponding requests to other nodes in the routing table. At the same time, the consensus node 1 starts to execute the transaction through the transaction execution module 13, stores the transaction result by using the storage module 19, and starts to assemble the message of the third PBFT phase, i.e. the commit phase, according to the rule of the PBFT.
Step S502: when the proxy node 1 of the sub-consensus network where the receiving consensus node 1 receives the request, the proxy node 1 obtains the routing table of the core main network where the proxy node is located through the storage module 19, then the proxy node 1 extracts part of the request data, assembles the broadcast message according to the request of the pre-preparation message in the first PBFT stage, that is, the pre-preparation stage, and starts broadcasting the pre-preparation message to other nodes of the core main network through the broadcasting request module 12 of the proxy node 1.
Step S503: when another proxy node 2 of the core main network receives a pre-preparation request, first, the proxy node 2 performs related verification on the pre-preparation message according to the PBFT rule, after verification, the proxy node 2 also sends the pre-preparation message of the proxy node 2 to the core main network, meanwhile, the proxy node 2 starts to count the consistent pre-preparation message received by the proxy node through the statistics module 15, and when the condition that the pre-preparation messages sent by other 2f nodes are received and all the pre-preparation messages are consistent, the proxy node 2 obtains a routing table of the sub-consensus network where the proxy node 2 is located through the storage module 19, and then the proxy node 2 starts to separate original request data from the request broadcast by the proxy node 1, assembles an internal message through the sending and receiving request module 11, and broadcasts a request transaction to other nodes in the sub-consensus network through the broadcasting request module 12 of the proxy node 2.
Step 504: and each proxy node in the core main network starts to perform three-stage consensus according to the rule of the PBFT algorithm, and after the core main network consensus is completed, each proxy node executes a transaction, and a transaction result and a commit message of a third phase of PBFT, namely a commit phase, are assembled into a new message and broadcast in each sub-consensus network.
Step S505: when the consensus node 2 of the sub-consensus network which does not receive the external request receives the request broadcasted by the corresponding proxy node 2 through the receiving and transmitting request module 11, the consensus node 2 executes the transaction through the transaction execution module 13, stores the transaction result through the storage module 19, and starts to assemble the message of the third phase of PBFT, namely the commit phase, according to the rule of the PBFT.
Step S506: when the consensus node of the sub-consensus network receives a new commit message broadcast by the proxy node through the transmit-receive request module 11, the new commit message includes commit message data owned by the proxy node after the core main network consensus third stage and a transaction result after the proxy node executes a transaction request. The common node 1 also reassembles the commit message according to the manner of the third phase of the PBFT, namely the commit phase, and broadcasts the commit message in the sub-common network where the common node 1 is located, and after the common node determines that other 2f consistent commit messages in the sub-common network have been received through the statistics module 18, the common node obtains the execution result of the corresponding transaction from the storage module 19, and if the execution result is consistent, the common node requests to package and uplink according to the packing rule.
Step S507: when the proxy node 2 receives other 2f consistent commit messages from the sub-consensus network, the proxy node 2 packages and chains the corresponding transaction via the storage module 19.
Step S508: when the consensus node 1 receiving the request normally executes the transaction according to the steps and verifies the result of the transaction, the consensus node 1 responds to the received request through the receiving and transmitting request device.
Step S509: when the consensus node 1 receiving the request normally executes the transaction according to the steps above but verifies that the transaction result does not pass, the consensus node 1 will pull the request transaction result and the corresponding block from other nodes in the sub-consensus network or pull the request transaction result and the block from other proxy nodes in the core main network by means of the proxy node 2 according to the principle of minority compliance and majority compliance, and respond to the received request according to the pulled transaction result.
Naturally, in actual work, the agent node receives the transaction request; for this reason, referring to fig. 6, in an embodiment of the present invention, a specific implementation flow of the blockchain consensus method is as follows:
step S601: the application system accessing the blockchain sends a request to a certain proxy node 1, and the proxy node 1 judges whether the request needs to modify the blockchain data, such as the world state, after receiving the request through the transceiving request module 11. The proxy node 1 converts the request into an internal request and tags the request message with corresponding labels according to whether the request needs to modify the blockchain data. The proxy node 1 uses the storage module 19 to obtain the routing table of the sub-consensus network where the current proxy node 1 is located, and broadcasts corresponding requests to other nodes in the routing table. In addition, the proxy node 1 acquires the routing table of the core main network by using the storage module 19, then the proxy node 1 extracts part of the request data, assembles the broadcast message according to the request of the pre-preparation message in the first PBFT stage, that is, the pre-preparation stage, and starts broadcasting the pre-preparation message to other nodes of the core main network through the broadcast request module 12 of the proxy node 1.
Step S602: when the consensus node 2 of the sub-consensus network which does not receive the external request receives the request broadcasted by the corresponding proxy node 2 through the receiving and transmitting request module 11, the consensus node 2 executes the transaction through the transaction execution module 13, stores the transaction result through the storage module 19, and starts to assemble the message of the third phase of PBFT, namely the commit phase, according to the rule of the PBFT.
Step S603: when another proxy node 2 of the core main network receives a pre-preparation request, first, the proxy node 2 performs related verification on the pre-preparation message according to the PBFT rule, after verification, the proxy node 2 also sends the pre-preparation message of the proxy node 2 to the core main network, meanwhile, the proxy node 2 starts to count the consistent pre-preparation message received by the proxy node through the statistics module 15, and when the condition that the pre-preparation messages sent by other 2f nodes are received and all the pre-preparation messages are consistent, the proxy node 2 obtains a routing table of the sub-consensus network where the proxy node 2 is located through the storage module 19, and then the proxy node 2 starts to separate original request data from the request broadcast by the proxy node 1, assembles an internal message through the sending and receiving request module 11, and broadcasts a request transaction to other nodes in the sub-consensus network through the broadcasting request module 12 of the proxy node 2.
Step S604: and each proxy node in the core main network starts to perform three-stage consensus according to the rule of the PBFT algorithm, and after the core main network consensus is completed, each proxy node executes a transaction, and a transaction result and a commit message of a third phase of PBFT, namely a commit phase, are assembled into a new message and broadcast in each sub-consensus network.
Step S605: when the consensus node of the sub-consensus network receives a new commit message broadcast by the proxy node through the transmit-receive request module 11, the new commit message includes commit message data owned by the proxy node after the core main network consensus third stage and a transaction result after the proxy node executes a transaction request. The common node also reassembles the commit message according to the manner of the PBFT third stage, namely the commit stage, and broadcasts the commit message in the sub-common network where the common node 1 is located, and after the common node determines that 2f other consistent commit messages in the sub-common network have been received through the statistics module 18, the common node obtains the execution result of the corresponding transaction from the storage module 19, and if the execution result is consistent, the common node wraps the request according to the packing rule.
Step S606: when the proxy node 1 receives other 2f identical commit messages from the sub-consensus network, the proxy node 1 packages and chains the corresponding transaction via the storage module 19.
Step S607: when the proxy node 1 receiving the request normally executes the transaction according to the steps but verifies that the transaction result does not pass, the proxy node 1 pulls the request transaction result and the block from other proxy nodes in the core main network according to the principle of minority compliance and majority compliance, responds to the received request according to the pulled transaction result, and synchronizes to each consensus node of the sub-consensus network where the proxy node is located.
The beneficial technical effects of the invention are as follows: the whole network is divided into a plurality of sub-consensus networks and a core main network in a hierarchical mode, and under the architecture, the number of times that a plurality of nodes need to communicate due to consensus is reduced; colleagues relatively improve throughput of the whole network response; in addition, in the consensus process, each node of the sub-consensus network can execute corresponding transaction in advance, and the transaction result is used as a verification standard, so that the node consensus process and the transaction executing process are parallel, and the performance of the whole network is improved to a certain extent. The PBFT three-stage is separated into nodes of different levels in a structure layering mode, so that the response time of the system is relatively reduced, and performance indexes such as throughput of the system are improved; architecture layering allows nodes that do not need to perform a complete consensus flow to perform transactions in advance, allowing for parallel processing of requested transaction execution and consensus.
The invention also provides an electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the above method when executing the computer program.
The present invention also provides a computer readable storage medium storing a computer program for executing the above method.
As shown in fig. 7, the electronic device 600 may further include: a communication module 110, an input unit 120, an audio processing unit 130, a display 160, a power supply 170. It is noted that the electronic device 600 need not include all of the components shown in fig. 7; in addition, the electronic device 600 may further include components not shown in fig. 7, to which reference is made to the related art.
As shown in fig. 7, the central processor 100, sometimes also referred to as a controller or operational control, may include a microprocessor or other processor device and/or logic device, which central processor 100 receives inputs and controls the operation of the various components of the electronic device 600.
The memory 140 may be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, or other suitable device. The information about failure may be stored, and a program for executing the information may be stored. And the central processor 100 can execute the program stored in the memory 140 to realize information storage or processing, etc.
The input unit 120 provides an input to the central processor 100. The input unit 120 is, for example, a key or a touch input device. The power supply 170 is used to provide power to the electronic device 600. The display 160 is used for displaying display objects such as images and characters. The display may be, for example, but not limited to, an LCD display.
The memory 140 may be a solid state memory such as Read Only Memory (ROM), random Access Memory (RAM), SIM card, or the like. But also a memory which holds information even when powered down, can be selectively erased and provided with further data, an example of which is sometimes referred to as EPROM or the like. Memory 140 may also be some other type of device. Memory 140 includes a buffer memory 141 (sometimes referred to as a buffer). The memory 140 may include an application/function storage 142, the application/function storage 142 for storing application programs and function programs or a flow for executing operations of the electronic device 600 by the central processor 100.
The memory 140 may also include a data store 143, the data store 143 for storing data, such as contacts, digital data, pictures, sounds, and/or any other data used by the electronic device. The driver storage 144 of the memory 140 may include various drivers of the electronic device for communication functions and/or for performing other functions of the electronic device (e.g., messaging applications, address book applications, etc.).
The communication module 110 is a transmitter/receiver 110 that transmits and receives signals via an antenna 111. A communication module (transmitter/receiver) 110 is coupled to the central processor 100 to provide an input signal and receive an output signal, which may be the same as in the case of a conventional mobile communication terminal.
Based on different communication technologies, a plurality of communication modules 110, such as a cellular network module, a bluetooth module, and/or a wireless local area network module, etc., may be provided in the same electronic device. The communication module (transmitter/receiver) 110 is also coupled to a speaker 131 and a microphone 132 via an audio processor 130 to provide audio output via the speaker 131 and to receive audio input from the microphone 132 to implement usual telecommunication functions. The audio processor 130 may include any suitable buffers, decoders, amplifiers and so forth. In addition, the audio processor 130 is also coupled to the central processor 100 so that sound can be recorded locally through the microphone 132 and so that sound stored locally can be played through the speaker 131.
It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
The foregoing description of the embodiments has been provided for the purpose of illustrating the general principles of the invention, and is not meant to limit the scope of the invention, but to limit the invention to the particular embodiments, and any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the invention are intended to be included within the scope of the invention.
Claims (8)
1. A blockchain consensus system, the system comprising a plurality of blockchain nodes, the blockchain nodes comprising a plurality of consensus nodes and a plurality of proxy nodes; wherein, a plurality of proxy nodes form a main network, and a plurality of consensus nodes and one proxy node form a sub-consensus network;
The consensus node is used for receiving a transaction request, broadcasting the transaction request to other consensus nodes in the sub-consensus network and the proxy node for verification processing; and receiving transaction requests broadcast by other consensus nodes in the sub-consensus network or transaction requests provided by agent nodes, generating preparation messages according to the transaction requests and broadcasting the preparation messages to the other consensus nodes in the sub-consensus network, and processing the transaction requests to generate transaction results when the number of the received preparation messages is higher than a preset threshold; comparing and verifying the transaction result with the consensus result fed back by the proxy node, and linking the transaction result or the consensus result according to the verification result;
the proxy node is used for consensus the transaction request to other proxy nodes in the main network through a Bayesian algorithm according to the transaction request broadcast by the sub-consensus network; obtaining a consensus result of the transaction request in the main network, and providing the consensus result to a sub-consensus network for comparison by the consensus node; the transaction request which is commonly recognized by other proxy nodes in the main network is obtained through a Bayesian algorithm, and the transaction request is provided to a sub-consensus network where the transaction request is located for processing by the consensus node;
The block chain node also comprises a node ordering module and a node role module;
the node ordering module is used for adjusting the identity information of the consensus node and the proxy node in the block chain link point according to a preset ordering rule, and updating the identity role of the current block chain node into the consensus node or the proxy node according to the adjusted identity information;
the node role module is used for recording the identity roles of the current blockchain nodes.
2. The blockchain consensus system of claim 1, wherein the blockchain node includes a transceiver request module, a broadcast request module, a transaction execution module, and a consensus module;
the receiving and transmitting request module is used for receiving a transaction request uploaded by an external application; or, receiving transaction requests broadcast by other consensus nodes in the sub-consensus network or transaction requests provided by proxy nodes;
the broadcasting request module is used for broadcasting the transaction request to the corresponding consensus node and the proxy node according to the IP addresses of other consensus nodes and the proxy node in the sub-consensus network;
the transaction execution module is used for processing the transaction request to generate a transaction result; comparing and verifying the transaction result with the consensus result fed back by the proxy node, and linking the transaction result or the consensus result according to the verification result;
The consensus module is used for splicing message messages in the consensus process of the Bayesian-preemptive consensus algorithm, and generating a preparation message according to the consistency of the message messages.
3. The blockchain consensus system of claim 2, wherein the blockchain node further comprises a filtering module and a statistics module;
the filtering module is used for obtaining the IP addresses of other consensus nodes and the proxy node according to the routing table of the sub-consensus network;
the statistics module is used for comparing the number of the received preparation messages with a preset threshold value, and when the number of the received preparation messages is higher than the preset threshold value, the transaction execution module is informed to process the transaction request to generate a transaction result.
4. A method of blockchain consensus, the method comprising:
dividing the blockchain nodes into consensus nodes and proxy nodes through preset rules, wherein a plurality of proxy nodes form a main network, and a plurality of consensus nodes and one proxy node form a sub-consensus network;
the consensus node receives a transaction request, and broadcasts the transaction request to other consensus nodes and the proxy node in the sub-consensus network for verification processing;
the other consensus nodes in the sub-consensus network where the consensus node is located generate preparation information according to the transaction request and broadcast the preparation information to the other consensus nodes in the sub-consensus network, and when the number of the received preparation information is higher than a preset threshold value, the transaction request is processed to generate a transaction result;
Obtaining a consensus result of the transaction request in the main network through a proxy node, and providing the consensus result to a sub-consensus network where the consensus result is located for comparison by the consensus node;
the consensus node compares and verifies the transaction result with the consensus result fed back by the proxy node, and links the transaction result or the consensus result according to the verification result;
and according to a preset ordering rule, adjusting the identity information of the consensus node and the proxy node in the block chain link point every preset period, and updating the identity role of the current block chain node into the consensus node or the proxy node through the adjusted identity information.
5. The blockchain consensus method of claim 4, wherein broadcasting the transaction request to other consensus nodes and the proxy node in the sub-consensus network for verification processing comprises:
the consensus node obtains the IP addresses of other consensus nodes and the proxy node according to the routing table of the sub-consensus network;
and broadcasting the transaction request to other consensus nodes and the proxy nodes in the sub-consensus network to perform verification processing through the IP address.
6. The blockchain consensus method of claim 5, wherein obtaining, by a proxy node, a consensus result of the transaction request at the primary network comprises: the proxy node commonly recognizes the transaction request to other proxy nodes in the main network through a Bayesian algorithm according to the transaction request broadcast by the sub-consensus network; and generating a consensus result according to the consensus situation of the transaction request in the main network.
7. The blockchain consensus method of claim 6, wherein obtaining the consensus result of the transaction request at the primary network further comprises:
after receiving the transaction request, other proxy nodes of the main network where the proxy nodes are located verify the transaction request, and broadcast verification results to other proxy nodes of the main network;
and receiving verification results broadcast by other proxy nodes, comparing the verification results with the self verification results, and broadcasting the transaction request to all consensus nodes in the sub-consensus network for processing when the number of the consistent comparison results is higher than a preset threshold value.
8. The blockchain consensus method of claim 7, wherein the predetermined threshold is 2f+1 nodes in a sub-consensus network where the consensus node is located or a master network where the proxy node is located; wherein f is the upper limit number of malignant nodes or the number of fault nodes in the sub-consensus network or the main network.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010310684.0A CN111539726B (en) | 2020-04-20 | 2020-04-20 | Block chain consensus system and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010310684.0A CN111539726B (en) | 2020-04-20 | 2020-04-20 | Block chain consensus system and method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111539726A CN111539726A (en) | 2020-08-14 |
| CN111539726B true CN111539726B (en) | 2024-03-19 |
Family
ID=71980100
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010310684.0A Active CN111539726B (en) | 2020-04-20 | 2020-04-20 | Block chain consensus system and method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111539726B (en) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111950036B (en) * | 2020-08-21 | 2023-11-14 | 交通银行股份有限公司 | Inter-block chain interaction system and method based on trusted distributed application |
| CN112785302B (en) * | 2020-12-30 | 2023-07-28 | 成都质数斯达克科技有限公司 | Message statistics method and device, electronic equipment and readable storage medium |
| CN112767152B (en) * | 2021-01-18 | 2024-02-09 | 中国工商银行股份有限公司 | Double-park disaster recovery system and method applied to alliance chain |
| CN112966048A (en) * | 2021-03-09 | 2021-06-15 | 安徽超清科技股份有限公司 | Block chain consensus method |
| CN112866421B (en) * | 2021-03-30 | 2023-02-24 | 中国工商银行股份有限公司 | Intelligent contract operation method and device based on distributed cache and NSQ |
| CN113329015B (en) * | 2021-05-28 | 2022-08-16 | 中邮信息科技(北京)有限公司 | Method, device, medium and electronic equipment for proxy of nodes of block chain |
| CN115499128A (en) * | 2021-06-01 | 2022-12-20 | 中移雄安信息通信科技有限公司 | Block chain consensus method, device, system and storage medium |
| CN113676355B (en) * | 2021-08-27 | 2024-04-23 | 浙商银行股份有限公司 | Block chain multi-level networking method, equipment and storage medium |
| CN113837758A (en) * | 2021-09-27 | 2021-12-24 | 深圳前海微众银行股份有限公司 | Consensus method and device for block chain system |
| CN113886495B (en) * | 2021-09-30 | 2024-05-24 | 支付宝(杭州)信息技术有限公司 | Method, device, electronic equipment and storage medium for verifying blockchain data |
| CN113973064B (en) * | 2021-12-24 | 2022-02-25 | 南京金宁汇科技有限公司 | Stability testing method and system based on block chain |
| CN114710507B (en) * | 2022-03-30 | 2023-10-27 | 蚂蚁区块链科技(上海)有限公司 | Consensus method, blockchain node, medium and consensus node |
| CN116208624B (en) * | 2023-05-05 | 2023-07-07 | 中航信移动科技有限公司 | Cross-environment block link point communication method, electronic equipment and storage medium |
| CN116720917A (en) * | 2023-06-16 | 2023-09-08 | 深圳职业技术学院 | Distributed carbon transaction market consensus method |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108616596A (en) * | 2018-05-09 | 2018-10-02 | 南京邮电大学 | It is adaptively known together method based on the block chain that dynamic authorization and network environment perceive |
| CN110113388A (en) * | 2019-04-17 | 2019-08-09 | 四川大学 | A kind of method and apparatus of the block catenary system common recognition based on improved clustering algorithm |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111543026B (en) * | 2018-12-13 | 2023-08-04 | 创新先进技术有限公司 | System for performing master node change in distributed network |
-
2020
- 2020-04-20 CN CN202010310684.0A patent/CN111539726B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108616596A (en) * | 2018-05-09 | 2018-10-02 | 南京邮电大学 | It is adaptively known together method based on the block chain that dynamic authorization and network environment perceive |
| CN110113388A (en) * | 2019-04-17 | 2019-08-09 | 四川大学 | A kind of method and apparatus of the block catenary system common recognition based on improved clustering algorithm |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111539726A (en) | 2020-08-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111539726B (en) | Block chain consensus system and method | |
| CN111897878B (en) | Master-slave data synchronization method and system | |
| CN111625593B (en) | Block chain-based data processing method and device and computer equipment | |
| CN111275555B (en) | Block chain transaction processing method, transaction node and block chain system | |
| US11783339B2 (en) | Methods and apparatuses for transferring transaction based on blockchain integrated station | |
| CN113347164A (en) | Block chain-based distributed consensus system, method, device and storage medium | |
| CN114092252B (en) | Block chain transaction execution method, device, equipment and readable storage medium | |
| CN112837163A (en) | Block chain based batch transaction uplink method and system | |
| CN111949614A (en) | Bank system file conversion method and device | |
| CN112837162A (en) | Data interaction method, node and system based on block chain | |
| CN111666589A (en) | Block chain distributed risk data sharing system and method | |
| CN110602338B (en) | Audio processing method, device, system, storage medium and equipment | |
| CN111813795B (en) | Method and apparatus for confirming transactions in a blockchain network | |
| CN112995317B (en) | Block chain consensus method and block chain link points | |
| CN111464628A (en) | Multiplexing asynchronous processing system and method | |
| EP3896931A1 (en) | Spark shuffle-based remote direct memory access system and method | |
| WO2019063019A1 (en) | Method and device for generating system information | |
| CN116684939B (en) | Message processing method, device, computer equipment and computer readable storage medium | |
| CN114629735B (en) | State interaction method, device, equipment and medium based on multiparty state channel | |
| CN112783853B (en) | Operation processing method, device and system based on block chain | |
| CN115426323B (en) | Network system, multicast traffic transmission method and device | |
| CN114584518B (en) | Websocket load balancing method and system based on resource pool | |
| CN117808467B (en) | Cross-fragment transaction method, device, equipment and medium based on blockchain network | |
| CN115277602B (en) | API gateway flow mirroring method | |
| US20230139834A1 (en) | Asynchronous network inventory 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 |