CN110555774A - Distributed consensus mechanism with arbitration - Google Patents
Distributed consensus mechanism with arbitration Download PDFInfo
- Publication number
- CN110555774A CN110555774A CN201910854428.5A CN201910854428A CN110555774A CN 110555774 A CN110555774 A CN 110555774A CN 201910854428 A CN201910854428 A CN 201910854428A CN 110555774 A CN110555774 A CN 110555774A
- Authority
- CN
- China
- Prior art keywords
- node
- transaction
- verification
- arbitration
- master
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000007246 mechanism Effects 0.000 title claims abstract description 30
- 238000012795 verification Methods 0.000 claims abstract description 223
- 238000000034 method Methods 0.000 claims description 25
- 239000003999 initiator Substances 0.000 claims description 3
- 230000006399 behavior Effects 0.000 abstract description 3
- 239000002699 waste material Substances 0.000 abstract description 3
- 230000008569 process Effects 0.000 description 22
- 230000008859 change Effects 0.000 description 9
- 238000012545 processing Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 238000010200 validation analysis Methods 0.000 description 2
- 230000004308 accommodation Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000012508 change request Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000005065 mining Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 238000012546 transfer Methods 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
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer And Data Communications (AREA)
Abstract
the invention relates to the field of distributed systems, in particular to a distributed consensus mechanism with arbitration. The consensus mechanism comprises: the system comprises an arbitration node, a main verification node, a transaction node and a verification node; the arbitration node is a final endorser of the system, has the trust of people, generally does not participate in consensus but only receives a final result, and intervenes in the normal work of a system auxiliary system when the system fails. On the premise that the system has at least one working honesty verification node, the system can work normally and does not have the behaviors of double flowers and the like. The verification nodes do not need to be excavated to avoid energy waste and improve efficiency. The master verification node leads the verification nodes to perform consensus within a period of time, and the master verification node has a rotation mechanism to adapt to possible profits of the master verification node.
Description
Technical Field
The invention relates to the field of distributed systems, in particular to a distributed consensus mechanism with arbitration.
Background
The consensus mechanism occupies a very central position in a distributed system. In a distributed system, it is often necessary to agree on a matter by following a certain protocol and communicating via communications between a plurality of nodes, which is a consensus mechanism. A common recognition mechanism has been studied for a long time, wherein a distributed scenario in which malicious nodes are not considered is called CFT (blast fault tolerance), and a distributed scenario in which malicious nodes are considered is called bft (byzantine fault tolerance). The scenario addressed by this patent is the BFT scenario.
The consensus mechanism for the BFT scenario includes a classical PBFT (Practical Byzantine Fault Tolerance) consensus algorithm, PoW (Proof of Work), PoS (Proof of rights and interests), and the like. Wherein PBFT requires the number of rogue nodes in the system to not exceed 1/3 and provides a deterministic consensus (results that will not be cancelled once validated), the latter two require the number of rogue nodes in the system to not exceed 1/2 and provide a probabilistic consensus (results that will be cancelled with some probability).
the existing distributed consensus mechanism has the following problems:
(1) Although the existing byzantine consensus mechanism can accommodate part of node failures, the existing byzantine consensus mechanism can only accommodate a certain proportion of node failures, and after a malicious node exceeds the accommodation proportion, serious consequences such as incapability of working of a system, inconsistent node states, double flowers and the like can be caused.
(2) The consensus mechanisms such as PoW rely on node mining, which is inefficient, consumes a large amount of energy, and has low performance.
(3) in a real business scenario, the final endorser of the system lacks the corresponding identity under the consensus mechanism.
Disclosure of Invention
In order to solve the technical problems described in the background art, the invention provides a distributed consensus mechanism with arbitration, and the concept of arbitration nodes is provided by aiming at the actual demands of the objective world. The arbitration node is the final endorser of the system, has the consistent trust of everyone, generally does not participate in consensus and only receives the final result, and intervenes in the system to assist the system to work normally when the system fails. For verification nodes, it is assumed that the system has at least one working honesty verification node. On the premise, the system can work normally and does not have the behaviors of double flowers and the like. The verification nodes of the system enter and exit through an auditing mechanism, and the verification nodes do not need to dig mines so as to avoid energy waste and improve efficiency. The master verification node leads the verification nodes to perform consensus within a period of time, and the master verification node has a rotation mechanism to adapt to possible profits of the master verification node.
The technical scheme adopted by the invention for solving the technical problems is as follows:
a decentralized consensus mechanism with arbitration, the consensus mechanism comprising:
The system comprises an arbitration node, a main verification node, a transaction node and a verification node; the arbitration node records all transaction information, the main verification node is designated by the arbitration node, the transaction node stores transaction data related to the transaction node, and the verification node accounts all the transaction data.
Specifically, the transaction information recorded by the arbitration node includes: confirmed transactions, transactions that have been received and are being confirmed, transactions that are rejected; the arbitration node maintains the switching order of the master verification nodes and broadcasts periodically or aperiodically.
Specifically, the transaction node is an initiator of the transaction, signs the transaction first, and sends the signed transaction to any verification node for verification, and when a request is sent, the transaction node needs to wait for the result of whether the transaction is successful.
Specifically, the master verification node responds to the following information: the transaction request sent by the transaction node or the transaction verification request forwarded by other verification nodes, the accounting request sent by the arbitration node, the request sent by the arbitration node for updating the main verification node and the transaction serial number returned to the arbitration node;
The master verification node sends out the following information: the method comprises the steps of sending verification requests to other verification nodes, sending arbitration requests to an arbitration node, and returning transaction results to a transaction node.
Specifically, the transaction data accounted by the verification node is divided into: confirmed transactions, transactions that are being confirmed, transactions that are rejected.
specifically, the confirmed transactions are arranged into a global sequence, the ordering of the global sequence includes term and seq, wherein term represents a main verification node, seq is a serial number determined by the main verification node, term is a number, when the arbitration node determines the next main verification node, term + + is performed, after the main verification node determines, the main verification node self-assigns a serial number seq, the correct main verification node self-increments seq, term and seq together form a global order, the verification node also records the current information of term and seq, and each confirmed transaction also has the information of its term and seq.
The invention has the beneficial effects that: the invention provides a distributed consensus mechanism with arbitration, and provides a concept of an arbitration node by aiming at the actual requirements of the objective world. The arbitration node is the final endorser of the system, has the consistent trust of everyone, generally does not participate in consensus and only receives the final result, and intervenes in the system to assist the system to work normally when the system fails. For verification nodes, it is assumed that the system has at least one working honesty verification node. On the premise, the system can work normally and does not have the behaviors of double flowers and the like. The verification nodes of the system enter and exit through an auditing mechanism, and the verification nodes do not need to dig mines so as to avoid energy waste and improve efficiency. The master verification node leads the verification nodes to perform consensus within a period of time, and the master verification node has a rotation mechanism to adapt to possible profits of the master verification node.
Drawings
The invention is further described with reference to the following figures and examples.
FIG. 1 is a schematic diagram of the framework of the present invention;
Detailed Description
The invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams illustrating only the basic structure of the invention in a schematic manner, and thus show only the constitution related to the invention.
fig. 1 is a schematic diagram of the framework of the present invention.
As shown in FIG. 1, at system initialization, the arbitration node designates or follows the initialization convention an initial master authentication node. The transaction node sends the transaction to the main verification node (or selects any verification node, and then the verification node forwards the transaction to the main verification node), the main verification node verifies whether the transaction has double flowers and the like, if the transaction is not rejected, the main verification node puts the transaction into a transaction pool.
The main verification node selects the transactions in the transaction pool and distributes serial numbers to the transactions in sequence, then signs the transactions and broadcasts the signatures to other verification nodes, and the other verification nodes sign the transactions and reply to the main verification node after receiving the transactions and verifying the validity. And when the main verification node collects the signatures of all the verification nodes, the transaction node is informed that the transaction is successful and all the verification nodes are informed that the transaction is successfully submitted (the signatures of all the nodes are carried as evidence).
If the main verification node fails to collect the signatures of all the verification nodes within a certain time, the transaction is reported to an arbitration node, the arbitration node determines whether the transaction is valid, if so, the transaction is signed and replied to the main verification node, and the main verification node informs the transaction node that the transaction is successful and informs all the verification nodes that the transaction is successfully submitted (the signatures of the arbitration nodes are taken as evidence).
The above is the work flow when the main verification node works normally.
When the main verification node cannot normally work due to downtime, Byzantine errors and the like, the arbitration node synchronizes information to all working verification nodes, then the main verification node is replaced, all the verification nodes are informed, the latest verification node list is updated, and then the normally working verification nodes work according to the new verification node list and the new main verification node in the process shown above.
One, node save data
The transaction node: transaction data associated with the present transaction node is stored. Verifying the node: the verification node accounts for all transactions. Transaction data is divided into three parts: the first part is a transaction that has been confirmed; the second part is that the transaction has been received, and is being confirmed. The confirmed transactions are arranged into a global sequence, the ordering of which includes (term, seq). Where term represents a master authentication node and seq is a serial number determined by the master authentication node. term is a number that is self-incremented by the arbitration node when it determines the next master verification node. After the main verification node determines that the sequence number seq is distributed by the main verification node, and the correct main verification node performs self-increment operation on the seq. (term, seq) together constitute a global order. The verification node also records the current (term, seq) information, as does each validated transaction. The third part is the transaction that is rejected for various reasons, and this part of the transaction is only information recorded.
An arbitration node: the arbitration node also records all transaction information and also comprises two parts, wherein the first part is the confirmed transaction; the second part is that the transaction has been received, and is being confirmed; the third part is transactions that are rejected for various reasons, which are only information recorded. In addition, the arbitration node maintains the switching order of the master authentication node and broadcasts it periodically or aperiodically, i.e., maintains the correspondence of such information (term, master), term number, and master.
Second, transaction node workflow
The transaction node is the initiator of the transaction, and all actions are initiated by the transaction node first.
The transaction node initiates a transaction: the transaction node signs a transaction first and sends the transaction to any verification node for verification (any verification node can be selected, a node closest to the transaction node can be generally selected, and if the closest node is not connected, any known verification node can be selected).
The transaction node initiates a transaction process:
1. the transaction node initiates a transaction request and signs according to the instruction, and confirms that the transaction can be initiated.
2. The transaction node is connected with any one of the verification nodes. Any verification node can be selected, a node closest to the verification node can be selected generally, and if the closest node is not connected, any known verification node can be selected. After issuing the request, the transaction node needs to wait for the result.
3. The transaction node waits for the returned result of the verification node. If the transaction is successful, the verification node returns a success. If the transaction fails to be verified, the verification node returns a failure and explains the failure reason.
4. If the transaction node does not receive any information within the specified time, the transaction node can inquire any other verification node about the transaction passing condition. Information on the success or failure of the transaction can be known.
5. If the transaction node does not receive any information for confirming whether the transaction is successful or not after initiating the transaction, the transaction node can think that an undetermined error occurs in the transaction, and can not confirm that the transaction is successful or confirm that the transaction is failed, and the transaction is in a pending state. The transaction node reports to the administrator that the transaction was pending.
Selection of main verification node and transaction sequencing
The master authentication node may be designated by the arbitration node. In the arbitration node, a count of one term is maintained, each term corresponding to one master authentication node. Each time a master verification node needs to be updated, the arbitration node causes term to be self-increasing (term + +). When the data is added, the data is firstly persisted (recorded in a disk, namely, logged in the disk), and then the information after the persistence is used.
Opportunity for master verification node replacement: the master authentication node may be updated whenever the arbitration node finds it necessary. Including the time-out replacement, requires the addition or subtraction of one authentication node.
Determination of the next master verification node: the arbitration node selects the next master verification node by a random method. After a period of time, any one of the verification nodes is rotated into the master verification node.
The main verification node replacement process comprises the following steps: in the process of replacing the master authentication node, it must be ensured that the new master authentication node must have a submitted transaction that the old master authentication node has already confirmed, otherwise the transaction may disappear. If the transaction has not been confirmed, no impact will be caused. The flow of arbitration node changes to the master verification node follows. Each step of the flow is a messaging process.
1. The arbitration node sends the information request-change for updating the main verification node to all the verification nodes and waits for the response of the verification nodes.
2. All the verification nodes receiving the request-change message give own response, and the content of the response comprises the latest confirmed transaction in the local or the transaction which is sent by the old main verification node and requires verification. Since the transaction is an authentication transaction, the last transaction is either the established transaction or the transaction of the authentication request from the old master authentication node, and the transaction contains (term, seq) information. After receiving this message, the correct verifying node stops working and waits for further instructions from the arbitrating node. Thus, even if the master authentication node issues an authentication request thereafter, authentication is not performed any more. The arbitration node can actually synchronize data with all verification nodes that can be contacted during the process.
3. The arbitration node collects all the verification node data as much as possible until all the verification node data is collected or a time-out occurs. The arbitration node integrates all the obtained information and sends out a message (change-master, term, master, last-tx, verifier-list) for changing the main verification node. Wherein, change-master describes that the current message is a change master verification node, term is the number of the master verification node for rotation, master is the information (such as the name of a machine or the ip address) of the master verification node, and last-tx is the number and content of the last transaction. last-tx may be a transaction that has been submitted in the previous round or a transaction that the old master authentication node requested for authentication. If the old master authentication node requests an authenticated transaction, then in the present case, an arbitrated commit is made by the arbitrating node. The last part of this request is the verifier-list, which indicates the list of all the verification nodes for the current round. In this way, it is also convenient to add and subtract verification nodes in the system.
Adding or reducing verification nodes: the flow of adding or subtracting authentication nodes may be added to the flow of the master authentication node change. In each change of the main verification node, a list of the verification nodes in the next round can be attached, so that the addition of the verification nodes can be finished in a forward manner, or the work flow of the verification nodes is reduced.
Fourth, the work flow of the main verification node
The primary authentication node is primarily responsive to the following categories of information: (1) a transaction request sent by a transaction node or a transaction verification request forwarded by other verification nodes; (2) accounting requests issued by the arbitration node (arbitration pass or fail); (3) a request issued by an arbitration node to update a master verification node; (4) the transaction sequence number is returned to the arbitration node.
The information that the master authentication node needs to send out includes the following categories: (1) sending an authentication request to other authentication nodes; (2) sending an arbitration request to an arbitration node; (3) the transaction results are returned to the transaction node (if the current master node received the transaction request).
The workflow of the master verification node is as follows.
The working process is as follows: processing a transaction request sent by a transaction node or a transaction verification request forwarded by other verification nodes:
(1) And receiving a transaction request sent by the transaction node, and verifying whether the format of the transaction request is correct and whether double flowers exist. If the verification fails, the transaction is rejected and recorded as a log, and the transaction is processed until the end. And receiving the transaction request forwarded by other forwarding nodes, and verifying whether the transaction format is correct and whether double flowers exist. If the opinion is inconsistent with the forwarded trading node, an arbitration request is made to the arbitration node.
(enter arbitration process.)
(2) The transaction is signed and then broadcast to all verification nodes requesting that each verification node verify the transaction, while a timer is started.
(3) Replies are collected for other verification nodes. If all the verification nodes approve and sign the transaction within the time specified by the timer, the transaction nodes are informed that the transaction is successful, and the main verification node can broadcast the transaction containing all the signatures to all the verification nodes at the same time, and the transaction processing is finished. Otherwise, the timer is terminated or the transaction is not approved by the verification node, and then the arbitration process is entered.
(4) and the master verification node sends the transaction and all received signatures to the arbitration node, and waits for the arbitration node to determine the transaction state. If the arbitration of the arbitration node passes, the main verification node passes the transaction and informs the transaction node of successful transaction; otherwise, the transaction is rejected and the transaction node is informed that the transaction fails.
And 2, a work flow: the old master verification node updates the work flow of the master verification node:
(1) The old master verification node receives the information request-change which is sent by the arbitration node and used for updating the master verification node.
(2) And the old master verification node suspends the current accounting work and synchronizes the current local account book information according to the requirements of the arbitration node.
(3) The old master verification node waits for the message (change-master, term, master, last-tx, verifier-list) sent by the arbitration node for changing the master verification node.
(4) When the old master verification node receives (change-master, term, master, last-tx, verifier-list), if a transaction submitted through arbitration exists in the last-tx, the transaction is submitted. And then, the old master verification node converts the identity of the old master verification node according to the master information.
And 3, a work flow: the new main verification node updates the work flow of the main verification node:
(1) And the new main verification node receives the information request-change which is sent by the arbitration node and used for updating the main verification node.
(2) And the new main verification node suspends the current accounting work and synchronizes the current local account book information to the arbitration node according to the requirement of the arbitration node.
(3) The new master verification node waits for a message (change-master, term, master, last-tx, verifier-list) sent by the arbitration node to change the master verification node.
(4) When the new master verification node receives (change-master, term, master, last-tx, verifier-list), if there is a transaction submitted through arbitration in last-tx, the transaction is submitted. The new master verification node switches its own identity to the master verification node and works with the identity of the master verification node throughout term.
And 4, a work flow: the main verification node distributes the work flow of the transaction serial number:
(1) the master authentication node receives a request from the arbitration node to assign a transaction sequence number.
(2) The master verification node checks whether the transaction has been assigned a transaction sequence number. If a transaction sequence number has been assigned for the transaction, the transaction sequence number is returned.
The other authentication node requests arbitration for a transaction that is not assigned a serial number because the other authentication node has an unacknowledged transaction that is not responded to late. It is possible that the master verification node is functioning properly or not functioning properly at this time. If the arbitration node only needs to forward (corresponding to the case of assigning sequence numbers here) under the condition that the master verification node is working normally. However, if the master authentication node has a problem, the arbitration node is required to perform the master authentication node replacement operation.
fifth, workflow of other verification nodes
The verification node mainly responds to the following types of information: (1) a transaction request issued by a transaction node; (2) a validation request for the transaction issued by the master validation node; (3) issuing an accounting request (verification is passed) by the main verification node; (4) accounting requests issued by the arbitration node (arbitration pass or fail); (5) a request issued by the arbitration node to update the master authentication node.
The information that the verifying node needs to send out includes the following categories: (1) forwarding the transaction verification request to a primary verification node; (2) sending an arbitration request to an arbitration node; (3) returning transaction result information to the transaction node; (4) the transaction record is sent to the arbitration node (all verification nodes verify, but the arbitration node does not necessarily have, and the transaction receiving node is responsible for the transfer).
Thus, the time-out information that the verifying node needs to process includes: (1) overtime processing of transaction request verification sent to the main verification node; (2) an arbitration timeout is issued to the arbitration node. In addition, when the transaction node results are returned, the timeout is not handled because, as is relatively simple, the transaction node will actively initiate the query.
The following is the process flow of the verification node:
The working process is as follows: the flow of the verification node responding to the transaction request is as follows:
(1) And the verification node receives the transaction request sent by the transaction node and verifies whether the format is correct and whether double flowers exist. If the verification fails, the transaction is rejected and recorded as a log, and the transaction is processed until the end. (correct node treated as such, incorrect node not assumed.)
(2) The authentication node forwards the transaction to the master authentication node, and the authentication node starts a timer. The verifying node may piggyback its own verified signature.
(3) The authentication node waits for the master authentication node to initiate normal transaction processing flow to determine if the transaction is committed. If the timer expires without determining the transaction status, the transaction is submitted to the arbitration node. Otherwise, the transaction state is informed to the transaction node, and the transaction is ended.
(4) The verifying node waits for the arbitration node to finally determine the transaction state and informs the transaction node.
And 2, a work flow: the verification node responds to the main verification node to verify the transaction:
(1) and the verification node receives the verification request of the main verification node, checks whether the format of the verification request is correct or not, and verifies the signature of the main verification node. And if the check fails, refusing to validate the transaction signature, responding to the verification failure to the main verification node, and ending the verification request.
(2) The verifying node checks whether all transactions before the sequence number of the verified transaction are owned locally and the state of the transactions is determined, if partial transactions are lacked, the transactions are refused to be signed as valid transactions, otherwise, the transactions are signed as valid transactions, a timer is started for the transactions to wait for the accounting request of the main verifying node, and the verification request is responded to and ended.
(3) And the verifying node submits the transaction for accounting after receiving the accounting request of the main verifying node for the transaction, and the flow of the verifying node for the transaction is ended. Otherwise, if the timer is overtime and the accounting request result for the transaction is still not received, the transaction is submitted to the arbitration node for arbitration.
(4) The verifying node waits for the arbitration result of the arbitration node and marks the transaction as valid or invalid according to the arbitration node.
And 3, a work flow: the verification node responds to the request flow of the arbitration node for replacing the main verification node:
(1) The verification node receives a message request-change of the main verification node of the arbitration node.
(2) The verifying node suspends the accounting work of the current term and synchronizes the current local accounting information to the arbitration node according to the requirement of the arbitration node.
(3) The verifying node waits for the message (change-master, term, master, last-tx, verifier-list) of the arbitrating node to change the main verifying node.
(4) The verification node submits the unconfirmed transaction in the local account book according to the indication of the arbitration node when receiving (change-master, term, master, last-tx, verifier-list), and then starts the accounting work in the period of the new main verification node.
Sixthly, arbitration node working process
The arbitration node is mainly responsive to the following categories of information: (1) an arbitration request issued by an authentication node. (2) Partial transaction record information sent by the verification node; (3) configuration change requests (adding or subtracting authentication nodes) issued by the administrator.
The information that the arbitration node needs to send out includes the following categories: (1) arbitration result information for transactions. (2) A request is made to the authentication node to transmit the partial transaction information. (3) Replacing the information of the main verification node; (4) and updating the information of the system verification node.
the following is the arbitration node's workflow.
When the arbitration node processes the arbitration request, it needs to perform different processes according to the identity of the requesting party and the state of the transaction, and the flow of the processes will be discussed in a classification manner below.
The working process is as follows: if the arbitration requester is the main verification node of the current term, the flow is as follows:
(1) The arbitration node receives the arbitration request sent by the main verification node, and checks whether the format is correct, whether a correct signature is contained, and the like.
(2) the arbitration node checks to see if the local ledger has a completed transaction record to determine if the transaction is valid. If the arbitration node lacks a partial transaction record, a request is broadcast to the authentication node to transmit partial transaction information and a timer is started.
And the arbitration node waits for collecting the required reply or overtime of the timer, and gathers the collected partial transaction information to update the local account book of the arbitration node.
(3) The arbitration node arbitrates the transaction and then broadcasts the arbitration result to all verification nodes. Meanwhile, the arbitration node records other verification nodes with errors, and can start a configuration change process to remove the other verification nodes with errors when appropriate.
And 2, a work flow: if the arbitration requester is the other authentication node of the current term, but the transaction has been assigned a sequence number by the master authentication node of the current term, the flow is as follows:
(1) The arbitration node receives arbitration requests sent by other verification nodes, and checks whether the format of the arbitration request is correct, and whether the arbitration request contains correct signatures, serial numbers and the like.
(2) The arbitration node looks to see if the local ledger has a completed transaction record to determine if the transaction is valid. If the arbitration node lacks a partial transaction record, a request is broadcast to the authentication node to transmit partial transaction information and a timer is started. And the arbitration node waits for collecting the required reply or overtime of the timer, and gathers the collected partial transaction information to update the local account book of the arbitration node.
(3) The arbitration node arbitrates the transaction and then broadcasts the arbitration result to all verification nodes. Meanwhile, if the arbitration node cannot communicate with the main verification node for many times, a configuration change process can be started to replace the current main verification node.
and 3, a work flow: if the arbitration requester is the other authentication node of the current term, but the transaction has not been assigned a sequence number by the master authentication node of the current term, the flow is as follows:
(1) The arbitration node receives arbitration requests sent by other verification nodes, and checks whether the format is correct, whether a correct signature is contained, and the like.
(2) the arbitration node forwards the transaction to the master authentication node, requesting assignment of a sequence number, and starting a timer.
(3) If the arbitration node receives the distributed serial number reply of the main verification node, the transaction and the serial number thereof are broadcasted to all the verification nodes, and the transaction is not arbitrated under the process (actually, the information of the main verification node is forwarded). If the timer is overtime, the main verification node may be failed, and a configuration change process may be started to replace the current main verification node.
The configuration change, the replacement of the master authentication node and the updating of the system authentication node are all done by starting a new term, and the detailed flow of the process is described in the foregoing.
In light of the foregoing description of preferred embodiments according to the invention, many modifications and variations can be made by the worker skilled in the art without departing from the scope of the invention. The technical scope of the present invention is not limited to the content of the specification, and must be determined according to the scope of the claims.
Claims (6)
1. A distributed consensus mechanism with arbitration, the consensus mechanism comprising:
The system comprises an arbitration node, a main verification node, a transaction node and a verification node; the arbitration node records all transaction information, the main verification node is designated by the arbitration node, the transaction node stores transaction data related to the transaction node, and the verification node accounts all the transaction data.
2. The decentralized consensus mechanism with arbitration according to claim 1, wherein the transaction information recorded by the arbitration node comprises: confirmed transactions, transactions that have been received and are being confirmed, transactions that are rejected; the arbitration node maintains the switching order of the master verification nodes and broadcasts periodically or aperiodically.
3. the distributed consensus mechanism with arbitration as claimed in claim 1, wherein the transaction node is an initiator of the transaction, signs the transaction first, and sends the signed transaction to any verification node for verification, and the transaction node waits for the result of whether the transaction is successful or not when sending the request.
4. Decentralized consensus mechanism with arbitration according to claim 1, characterized in that said master authentication node responds to the following information: the transaction request sent by the transaction node or the transaction verification request forwarded by other verification nodes, the accounting request sent by the arbitration node, the request sent by the arbitration node for updating the main verification node and the transaction serial number returned to the arbitration node;
the master verification node sends out the following information: the method comprises the steps of sending verification requests to other verification nodes, sending arbitration requests to an arbitration node, and returning transaction results to a transaction node.
5. Decentralized consensus mechanism with arbitration according to claim 1, characterized in that the transaction data of the authentication node accounting is divided into: confirmed transactions, transactions that are being confirmed, transactions that are rejected.
6. The decentralized consensus mechanism with arbitration of claim 5, wherein said confirmed transactions are arranged in a global sequence, the sequence of the global sequence comprising term and seq, wherein term represents a master authentication node and seq is the serial number determined by the master authentication node, term is a number, when the arbitration node determines the next master authentication node, term + + is performed, after the master authentication node determines, the master authentication node self-assigns a serial number seq, the correct master authentication node performs a self-increment operation on seq, term and seq together form a global sequence, the authentication node also records the current information of term and seq, and each confirmed transaction also has the information of its term and seq.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910854428.5A CN110555774A (en) | 2019-09-10 | 2019-09-10 | Distributed consensus mechanism with arbitration |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910854428.5A CN110555774A (en) | 2019-09-10 | 2019-09-10 | Distributed consensus mechanism with arbitration |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110555774A true CN110555774A (en) | 2019-12-10 |
Family
ID=68739710
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910854428.5A Pending CN110555774A (en) | 2019-09-10 | 2019-09-10 | Distributed consensus mechanism with arbitration |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110555774A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112036878A (en) * | 2020-08-28 | 2020-12-04 | 平安科技（深圳）有限公司 | Data processing method and device |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106780025A (en) * | 2016-11-30 | 2017-05-31 | 中国银行股份有限公司 | The transfer method of digital asset, apparatus and system in block chain |
| CN109146483A (en) * | 2018-08-31 | 2019-01-04 | 刘涵 | Credit record method and system based on block chain network |
| CN109598616A (en) * | 2018-12-09 | 2019-04-09 | 大连飞创信息技术有限公司 | A method of introducing the block chain data-privacy protection of arbitration mechanism |
-
2019
- 2019-09-10 CN CN201910854428.5A patent/CN110555774A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106780025A (en) * | 2016-11-30 | 2017-05-31 | 中国银行股份有限公司 | The transfer method of digital asset, apparatus and system in block chain |
| CN109146483A (en) * | 2018-08-31 | 2019-01-04 | 刘涵 | Credit record method and system based on block chain network |
| CN109598616A (en) * | 2018-12-09 | 2019-04-09 | 大连飞创信息技术有限公司 | A method of introducing the block chain data-privacy protection of arbitration mechanism |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112036878A (en) * | 2020-08-28 | 2020-12-04 | 平安科技（深圳）有限公司 | Data processing method and device |
| WO2022041902A1 (en) * | 2020-08-28 | 2022-03-03 | 平安科技（深圳）有限公司 | Data processing method and apparatus |
| CN112036878B (en) * | 2020-08-28 | 2023-08-22 | 平安科技（深圳）有限公司 | Data processing method and device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11966916B2 (en) | Resource transfer method and apparatus, storage medium, and computer device | |
| CN110784331B (en) | Consensus process recovery method and related nodes | |
| JP6450471B2 (en) | System, method and computer program product for receiving electronic messages | |
| EP3234889A1 (en) | An interface, system, method and computer program product for controlling the transfer of electronic messages | |
| US20100332371A1 (en) | 24 hours global low latency computerized exchange system | |
| CN111711526A (en) | Consensus method and system for block chain nodes | |
| CN105183544A (en) | Non-blocking type fault-tolerant submitting method and system for distributed event | |
| CN110555774A (en) | Distributed consensus mechanism with arbitration | |
| CN113112344A (en) | Business processing method, device, storage medium and computer program product | |
| EP2891283B1 (en) | Resilient peer-to-peer application message routing | |
| CN114095209A (en) | Weight-incentive-based alliance chain consensus method and system for main node election | |
| US20040008678A1 (en) | System and method for managing transactions in a messaging system | |
| US7051065B2 (en) | Method and system for performing fault-tolerant online validation of service requests | |
| CN116232893A (en) | Consensus method and device of distributed system, electronic equipment and storage medium | |
| US20240013207A1 (en) | Method and system for performing electronic transactions | |
| CN113919835A (en) | Business processing method, device, storage medium and computer program product | |
| CN113722330A (en) | Method and device for retrying online transaction failure | |
| CN116991623B (en) | Block chain node exception recovery method and device, electronic equipment and storage medium | |
| CN116467390A (en) | Distributed data processing method, device, computer equipment and storage medium | |
| CN111222876A (en) | Method and system for solving cross-chain coupling | |
| WO2022127424A1 (en) | Obtaining method and apparatus for block group header, storage medium, and electronic device | |
| CN114971163A (en) | Execution method and execution device for re-initiating service request | |
| CN113010516A (en) | Distributed multi-user high-availability pedestrian report acquisition method based on session pool | |
| JP2002099510A (en) | Plural transactions processing system | |
| CN118802946A (en) | Distributed consensus method based on block chain and related equipment thereof |
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 | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20191210 |