CN111586168B - Waterline height changing and setting method - Google Patents

Waterline height changing and setting method Download PDF

Info

Publication number
CN111586168B
CN111586168B CN202010375633.6A CN202010375633A CN111586168B CN 111586168 B CN111586168 B CN 111586168B CN 202010375633 A CN202010375633 A CN 202010375633A CN 111586168 B CN111586168 B CN 111586168B
Authority
CN
China
Prior art keywords
value
view
waterline
consensus
height
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010375633.6A
Other languages
Chinese (zh)
Other versions
CN111586168A (en
Inventor
钱京
崔可
李婉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hengbao Co Ltd
Original Assignee
Hengbao Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hengbao Co Ltd filed Critical Hengbao Co Ltd
Priority to CN202010375633.6A priority Critical patent/CN111586168B/en
Publication of CN111586168A publication Critical patent/CN111586168A/en
Application granted granted Critical
Publication of CN111586168B publication Critical patent/CN111586168B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Retry When Errors Occur (AREA)

Abstract

The invention provides a waterline height change setting method which is characterized in that a first numerical value when the ith view is converted and a second numerical value when the (i +1) th view is converted are recorded and obtained, wherein i is a positive integer; and calculating a new waterline height by the main consensus node after the (i +1) th view conversion according to the first numerical value, the second numerical value and a preset rule recorded during the view conversion, and broadcasting the new waterline height to other consensus nodes. The invention sets the waterline height timer specially used for setting the waterline height, and the view conversion is related to the factors such as machine performance, network environment and the like, so the view conversion is taken as an event for triggering the reading of the waterline height timer, and when the view conversion occurs, the recorded time length represents the current machine performance or network performance, so that the working efficiency of the consensus system is more matched with related parameters, the consensus time is saved, and the consensus process is ensured to be carried out smoothly.

Description

Waterline height changing and setting method
Technical Field
The invention relates to the technical field of communication or computer, in particular to a method for changing and setting the height of a waterline, which is used for improving the speed of a consensus process in a block chain.
Background
In the process of the practical Byzantine fault-tolerant pbft (practical Byzantine fault tolerant), the client continuously pushes new requests to the consensus system, and through the consensus process of the consensus system, there are continuously requests executed by the consensus node, for example, uplink operation, and after the client receives a certain number of consistency results, the request completes a consensus period through the consensus system. In the consensus process, the consensus node needs to store a history of state information of the consensus process, and after the consensus node executes a request, in order to save storage space, the history of state information related to the request recorded before needs to be removed. However, the single consensus node cannot delete the history of the related status information directly after it has performed or has not performed the requested operation, because the consensus set (Quorum) of the consensus node and the consensus sets of other consensus nodes do not guarantee consistency, which is a necessary condition for practical byzantine fault tolerance achievement consensus. If the VIEW CHANGE message is required to carry the preparation phase information of the request which is not agreed yet, for example, during the VIEW CHANGE process, the VIEW CHANGE message cannot carry the accurate and complete preparation phase information of the request, which causes a system error during the VIEW CHANGE process, provided that the preparation phase information of the request in the previous VIEW is directly deleted by the consensus node as a history before the VIEW CHANGE. Thus, in designing a practical Byzantine fault tolerant consensus system, corresponding rules are formulated to ensure that status information for requests that have completed can be safely cleared.
In theory, after a consensus node executes a request, the status information of the request may be deleted, for example, by the consensus node asking other consensus nodes whether consensus is achieved, that is, whether a certain number of consistent execution results can be formed, and if consistent execution results are formed, the relevant information of the request may be deleted. However, if this method is adopted, after each request is executed by the consensus node, a broadcast is performed, and each consensus node that has executed the request sends the same broadcast, and each consensus node also receives broadcast messages of other consensus nodes to confirm whether the consensus node has agreed on the request, so that the status information of the request can be further deleted. As can be seen, this approach transmits and receives broadcasts in the consensus system every time a request is executed, which consumes significant communication resources and takes up a significant amount of time in the consensus process.
Therefore, in designing a practical byzantine fault tolerance, a common method is that a consensus node continuously executes N requests and, after the consensus node executes the nth request, broadcasts to other consensus nodes, notifies other consensus nodes that a consistency result has been achieved for the N requests, and waits for receiving the broadcasts of the other consensus nodes, or, after receiving the broadcasts of the other consensus nodes, verifies whether it has received the consistency result for the N requests and has completed the execution. Through the above process, if the execution results of a certain number of consensus nodes of the consensus system for the N requests meet the requirement of consistency, the state information of the N requests can be deleted on the corresponding consensus nodes. In summary, after each execution of N requests, the operation of broadcasting in the consensus system is called sending CHECKPOINT checkkoint message, and after receiving a certain number of messages broadcast by the consensus nodes, it indicates that the N requests have been executed by a certain number of consensus nodes, and a consensus of the certain number of consensus nodes is obtained, and a stable checkkoint (stable checkkoint) is formed at this time.
In an actual consensus process, it is assumed that a certain consensus node executes N requests and sends out broadcast of the checkkey information message to the consensus system, however, other consensus nodes do not execute N requests at this time, and therefore, other consensus nodes that do not execute N requests cannot timely send broadcast of their checkkey information messages, which results in that the consensus node that has executed N requests cannot determine whether to obtain consensus of a certain number of consensus nodes, and thus cannot delete status information of N requests. Meanwhile, the master consensus node that has executed N requests will continue to distribute the next requests, or the duplicate consensus node that has executed N requests will continue to receive the next requests, which may cause the master consensus node that has executed N requests to allocate a large number of request numbers without any restriction, or cause the duplicate consensus node that has executed N requests to far exceed the request numbers of other duplicate consensus nodes, or even send broadcasts of multiple chekpoint messages, backlogging and blocking a large number of consensus processes.
In practice, in order to avoid the above situation, the concept of the Waterline (WATERMARK) is set, with the following three parameters: low waterline L, waterline height K, high waterline H. Typically, the low water line L is set to the request number of the most recent stable CHECKPOINT; the waterline height K is the number of requests which can allow floating on the basis of low waterline, and is generally an empirical value, and values of 100, 200, 400 and the like are usually selected from related documents according to the conditions disclosed by the related documents at present; the high waterline H is L + K, i.e. the high waterline H is the sum of the low waterline L and the waterline height K. In this way, a value interval is set for the allocation of the request numbers and the execution quantity of the requests, and the numbers allocated to the requests and the execution quantity of the requests are ensured to be in a limited range. When the main consensus node distributes the number for the received request, if the number to be distributed is larger than the high waterline H, the number distribution is suspended, the updating of the stable CHECKPoint and the low waterline L is waited, and the number distribution is restarted after the updating; when the duplicate consensus node executes the requests according to the number sequence, if the number of the requests to be executed is larger than the high waterline H, the execution requests are suspended, the stable CHECKPOINT and the low waterline L are waited for updating, and the execution requests are restarted after the updating.
In summary, in order to save the storage space, the practical byzantine fault tolerance adopts a working mode of deleting state information or controlling a consensus process based on a fixed waterline height K, however, the fixed waterline height is not favorable for the consensus system to operate efficiently, and mainly causes the following problems.
One is that it will be affected by the network environment. Different network environments enable the sending or receiving speed of each consensus node to be different, the sending or receiving speed of the consensus nodes is high sometimes and low sometimes, if a fixed waterline height is adopted, under the network environment with high speed, the consensus nodes originally should implement a large amount of consensus processes and execute a large amount of requests, but due to the fixed waterline height, the consensus nodes with higher network speed have to stop, wait for other consensus nodes with low network speed to finish operation, and cause idle running of the consensus nodes, and conversely, because the time for the network consensus nodes with low speed to wait for received messages is longer, the consensus nodes with high network speed are in a waiting state for a long time, and waste processing time.
The second is that it will be affected by the performance of the machine. The common recognition nodes are often high-performance computers, the machine replacement time of the common recognition nodes is not synchronous as time goes on, a part of the common recognition nodes replace machines first, the other part of the common recognition nodes are not replaced, the processing speed and the performance of the computers in different batches are different, if the processing speed of a part of the common recognition nodes is higher than that of other common recognition nodes, the part of the common recognition nodes can reach a high-water line faster, the time for waiting for the other common recognition nodes to finish processing is longer, and precious processing time is wasted.
And thirdly, will be affected by hardware updates. According to experience, the hardware update speed exceeds that of software, so that under the condition that the hardware speed or performance is continuously improved, various settings or functions of the software are relatively stable, namely the software update period is longer than the hardware update period, which causes that the originally set water line height K is not suitable for the condition that the hardware performance is integrally improved, for example, when the machine processing speed and performance are multiplied, and the water line height K still maintains a value set under a slow condition, under the condition, a request processed by the consensus node reaches a high water line quickly, a part of the consensus node can be caused to interrupt a consensus process frequently, and the consensus system is not beneficial to work smoothly.
Disclosure of Invention
In order to solve the technical problem described in the background art, an embodiment of the present invention provides a method for changing and setting a waterline height. According to the running state and relevant parameters of the consensus system during the running period, the height of the waterline is continuously and dynamically adjusted, so that the waterline height is more suitable for the current system, the idle time of the consensus node can be reduced, the consensus period of the consensus process is saved, and the consensus system is guaranteed to work smoothly.
The embodiment of the application provides a waterline height change setting method which is characterized in that a first numerical value during view conversion of the ith time and a second numerical value during view conversion of the (i +1) th time are recorded and obtained, wherein i is a positive integer; and calculating a new waterline height by the main consensus node after the (i +1) th view conversion according to the first numerical value, the second numerical value and a preset rule recorded during the view conversion, and broadcasting the new waterline height to other consensus nodes.
The waterline height change setting method is characterized in that each consensus node is provided with a waterline height timer; the first numerical value is the value of a waterline height timer during the ith view conversion; the second value is the value of a waterline height timer during the (i +1) th view conversion; and calculating and determining a new waterline height by the main common recognition node after the (i +1) th view conversion according to the first numerical value and the second numerical value by using a preset rule, and broadcasting the new waterline height to other common recognition nodes.
The method for setting the CHANGE of the waterline height is characterized in that the first value is the difference value between the minimum value of the request numbers in the stable CHECKPOiNT set in the VIEW-CHANGE message and the maximum value of the request numbers in the PREPARE message set during the ith VIEW conversion; the second value is the difference value between the minimum value of the request numbers in the stable CHECKPoint set in the VIEW-CHANGE message and the maximum value of the request numbers in the PREPARE message set during the VIEW conversion of the (i +1) th time;
and calculating and determining a new waterline height by the main common recognition node after the (i +1) th view conversion according to the first numerical value and the second numerical value by using a preset rule, and broadcasting the new waterline height to other common recognition nodes.
The method for setting the change of the waterline height is characterized in that the request number without the PREPARE message set between the maximum value of the request number and the minimum value of the request number during the ith view conversion is counted, the request number without the PREPARE message set is subtracted from the first numerical value, and the value obtained after the subtraction is used as a corrected first numerical value; counting the number of requests without a PREPARE message set between the maximum value of the request number and the minimum value of the request number during the view conversion of the (i +1) th time, subtracting the number of requests without the PREPARE message set from the second value, and taking the value obtained after subtraction as a corrected second value; and calculating and determining a new waterline height by the main common recognition node after the (i +1) th view conversion according to the corrected first numerical value and the corrected second numerical value by using a preset rule, and broadcasting the new waterline height to other common recognition nodes.
The waterline height change setting method is characterized in that the preset rule is that a quotient obtained by dividing a second numerical value obtained by the (i +1) th view conversion by a first numerical value obtained by the (i) th view conversion is used as a weight, and the weight is multiplied by the waterline height after the (i) th view conversion to obtain a new waterline height.
The waterline height change setting method is characterized in that the preset rule is that a quotient obtained by dividing a second numerical value recorded by the (i +1) th view conversion by a first numerical value recorded by the (i) th view conversion is used as a weight, and the weight is multiplied by the waterline height during the (i) th view conversion to obtain a new waterline height; if the recorded numerical value is a numerical value of a digital display height timer, the first weight is the numerical value of the waterline height timer at the i +1 th view conversion time divided by the waterline height timer at the i th view conversion time; if the recorded numerical value is the difference between the minimum value of the request numbers in the stable CHECKOINT set in the VIEW-CHANGE message and the maximum value of the request numbers in the PREPARE message set, the second weight value is the difference between the minimum value of the request numbers in the stable CHECKOINT set in the VIEW-CHANGE message and the maximum value of the request numbers in the PREPARE message set at the i +1 th VIEW conversion time, and is divided by the difference between the minimum value of the request numbers in the stable CHECKOINT set in the VIEW-CHANGE message and the maximum value of the request numbers in the PREPARE message set at the i th VIEW conversion time; if the recorded value is the value obtained by subtracting the number of requests without PREPARE message set between the maximum value of the request number and the minimum value of the request number from the difference between the minimum value of the request number in the stable CHECKOINT set in the VIEW-CHANGE message and the maximum value of the request number in the PREPARE message set, the third weight is the value obtained by subtracting the number of requests without prefix message set between the maximum value of the request number and the maximum value of the request number in the prefix message set from the difference between the minimum value of the request number in the stable checksum point set in the VIEW-CHANGE message at the i +1 th VIEW transition by subtracting the number of requests without prefix message set between the maximum value of the request number and the maximum value of the request number in the stable checksum point set in the VIEW-CHANGE message at the i th VIEW transition by subtracting the number of requests without prefix message set between the maximum value of the request number and the minimum value of the request number; and calculating a new waterline height according to at least two of the weights.
The waterline height change setting method is characterized in that the maximum value of the first weight, the second weight and the third weight or the maximum value between every two of the first weight, the second weight and the third weight is taken, and the maximum value is multiplied by the current waterline height to obtain a new waterline height.
The waterline height change setting method is characterized in that when the consensus is started for the first time, the initial value of the waterline height is an empirical value.
The waterline height changing and setting method is characterized in that after the common identification is started, if i is 1, when the view is converted, the numerical value of a waterline height timer is recorded, the waterline height timer is reset, and the waterline height is not changed and set.
According to the waterline height change setting method, when the second round view is converted, the numerical value of the waterline height timer is recorded, the waterline height timer is reset, and the waterline height is changed and set.
According to the method for changing and setting the waterline height, when the VIEW is converted, the numerical value of a waterline height timer is recorded, the waterline height timer is reset, and on a main common node of a NEW VIEW, when the VIEW is converted, the main common node of the NEW VIEW sends a NEW-VIEW message to other common nodes; on other consensus nodes, the time when the VIEW is converted refers to the time when the other consensus nodes receive a NEW-VIEW message of the main consensus node.
According to the method for changing and setting the waterline height, when the VIEW is converted, the numerical value of a waterline height timer is recorded, the waterline height timer is reset, and on a main common node of a NEW VIEW, when the VIEW is converted, the main common node of the NEW VIEW sends a NEW-VIEW message to other common nodes; on other consensus nodes, the time when the VIEW is converted refers to the time when the other consensus nodes receive a NEW-VIEW message of the main consensus node.
According to the technical scheme, the waterline height timer special for setting the waterline height is arranged, the view conversion is related to factors such as machine performance and network environment, the view conversion is used as an event for triggering reading of the waterline height timer, when the view conversion occurs, the numerical value of the waterline height timer is recorded, the waterline height timer is reset, the recorded time length represents the current machine performance or network performance, namely the corresponding waterline height is changed and set according to the machine performance or network performance, so that the waterline height after the change of the setting is more suitable for the current consensus system, the aim of matching the working efficiency of the consensus system with related parameters is fulfilled, the consensus time is saved, and the consensus process is guaranteed to be carried out smoothly.
Drawings
Figure l shows the flow of practical byzantine fault tolerance in the prior art.
Fig. 2 shows a basic flow of view conversion in the prior art.
FIG. 3 shows a schematic diagram of an exemplary consensus node layout of the present invention.
FIG. 4 is a schematic diagram showing a procedure for carrying out the steps of exemplary embodiment 1 of the present invention.
FIG. 5 is a schematic diagram showing a procedure for executing the steps of exemplary embodiment 2 of the present invention.
FIG. 6 is a schematic diagram showing a procedure for executing the steps of exemplary embodiment 3 of the present invention.
Fig. 7 is a schematic diagram showing the principle of correction of the corrected difference value according to the present invention.
FIG. 8 is a schematic diagram showing the procedure of the step execution of exemplary embodiment 4 of the present invention.
Detailed Description
The embodiment of the application provides a method for changing and setting the height of a waterline. According to the running state and relevant parameters of the consensus system during running, such as the time length consumed during view conversion, the height of the waterline is continuously and dynamically adjusted, so that the waterline height after changing the setting is more suitable for the current consensus system, the aim of more matching the working efficiency of the consensus system with the relevant parameters is fulfilled, the pause times of consensus nodes can be reduced, the consensus time of the consensus process is saved, and the consensus system is guaranteed to work smoothly.
The terms in the abstract, the description, the claims, the drawings and the like (if any) are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order by virtue of the technical features. Features so used will be understood by those skilled in the art to be interchangeable under appropriate circumstances such that the embodiments described herein may be practiced in other sequences than as specifically illustrated or described herein. Moreover, the terms "comprises," "comprising," and any other variations thereof, are intended to cover other embodiments not necessarily limited to the explicitly recited steps, but may include other steps not explicitly recited or required for such processes, methods, and other steps.
The practical Byzantine fault tolerance comprises a plurality of basic nodes, including a client, a main consensus node and a duplicate consensus node, wherein the main consensus node and the duplicate consensus node are consensus nodes which need to execute a consensus process, and the request and the message are copied; the client, an initiator of the consensus process, initiates a request to the main consensus node, wherein the request comprises transaction information needing consensus, and the node can be the same node as the main consensus node in a block chain at times; the master consensus node starts a consensus process, generates a new block after receiving the request from the client and broadcasts the new block to each consensus node; the process of the consensus node verification block is to actually verify the request sent by the main consensus node, verify the request after receiving the request, and then broadcast the verification result to other consensus nodes including the main consensus node to execute the consensus process.
In the process of executing consensus, a combined mode of the main consensus node and the duplicate consensus node forms a view, and a consensus process is completed on the blocks on the view; at the end of consensus, if an acknowledgment is received that exceeds 2/3, it is called a checkpoint. The change of the view is started every time the main common knowledge node or the common knowledge node is changed, the change of the view is generally performed in a broadcasting mode, or the change of the view can be completed through common knowledge operation, for example, when the common knowledge nodes including the main common knowledge node have problems of downtime, disconnection and the like, a new view appears, and the new view selects a new main common knowledge node.
The prior art common recognition process of practical byzantine fault tolerance mainly comprises three stages, as shown in fig. 1, namely, a Pre-preparation (Pre-preparation), a preparation (preparation), and a Commit confirmation (Commit), and a Request (Request) and a Reply (Reply) are included before the three stages. In the pre-preparation stage, the main consensus node assigns a sequence number n to the request information sent by the client, and then broadcasts the request information to other consensus nodes. The format of the broadcast PRE-preparation information is PRE-PREPARE, v, n, d, m, where v denotes the view number, n denotes the sequence number assigned to the message carried in the request, m is the message requested by the client and will be uploaded to the block chain after reaching consensus, and d is the summary information of the message m. When the consensus node of the network receives the pre-preparation message, the following conditions need to be satisfied: firstly, the signatures of the request message and the pre-prepared message are verified and the result is correct, wherein the digest information of the message m is the same as d; secondly, the view number of the current consensus node is the same as the view number v in the received pre-preparation information; third, the consensus node does not receive a message with sequence number n in the view with view number v, and the message digest d is not identical to the message with sequence number m. When the conditions are met, the consensus node receives the pre-preparation message and enters the next preparation stage. When the PRE-preparation information < < PRE-PREPARE, v, n, d >, m > received by the consensus node in the consensus node set, the consensus node enters a preparation stage, and sends a preparation message < PREPARE, v, n, d, i > to all the consensus nodes in the consensus node set, when the consensus node receives the preparation message, the following conditions need to be satisfied: firstly, whether the signature of the message is correct, secondly, whether the view numbers are consistent, and thirdly, whether the sequence number of the message is below a high water line, that is, the message cannot be advanced too much, the message currently at the consensus node is continuously processed, and the sequence number of the message is below the water line, so that the consensus process is not started. When the consensus node receives 2f +1 view numbers V (V1, V2, … …, V (2f +1)), the message sequence number n and the message digest d are both consistent with the preparation message of the pre-preparation phase message, the consensus node finishes the consensus processing of the preparation phase and enters the next submission phase. When the consensus node i needs to verify that (m, v, n, i) is correct, < COMMIT, v, n, D (m), i > is broadcast to other consensus nodes in the set of consensus nodes. When the consensus node receives the acknowledgement message, the following conditions need to be satisfied: first, the signature of the confirmation message is correct, second, the view number of the confirmation message is the same as the view number of the preparation phase, and third, the message sequence number n is within a specified range. When the above conditions are all satisfied, the confirmation message is accepted by the consensus node. If the consensus node receives 2f +1 identical acknowledgement messages, the messages are acknowledged by most of the nodes in the set of consensus nodes.
In the reply phase, each consensus node sends Commit acknowledge information to the client and the consensus node will delete message sequences with timestamps smaller than t. When the client receives 2f +1 identical reply messages, the client indicates that most of the consensus nodes in the network generate consensus results and the consensus results are effective, namely, the practical Byzantine fault-tolerant consensus process initiated by the client is completed, and the corresponding messages are uploaded to the block chain.
FIG. 2 is a flow of VIEW conversion in the prior art, which mainly includes three stages, a first stage in which each duplicate consensus node discovers that a main consensus node is down or disconnected, broadcasts and sends VIEW-CHANGE messages to other duplicate consensus nodes in a consensus system, determines a next VIEW and a new main consensus node, a second stage in which each duplicate consensus node receives VIEW-CHANGE messages broadcast and sent by other duplicate consensus nodes, after receiving a certain number of VIEW-CHANGE messages, the consensus system forms consensus on the next VIEW and the new main consensus node, and each duplicate consensus node sends ACK messages to the new main consensus node, indicating that the new main consensus node can exercise the right in the new VIEW; and in the third stage, after receiving a certain number of ACK messages, the NEW main consensus node broadcasts a NEW-VIEW message to each duplicate consensus node and starts to resend the Pre-Prepare message.
Fig. 3 shows an example of the layout of the consensus node according to the present invention, where 301 is a peripheral device, which may be a terminal, a computer, an intelligent device, a machine communication device, etc., 302 is a client, and may also be a primary consensus node, 303 is a primary consensus node or a consensus node (duplicate consensus node), and 304 and 306 are consensus nodes (duplicate consensus nodes).
Example one
As an example, as shown in fig. 4, in this embodiment, each common node is provided with a timer as the waterline height timer TWMThe timer can be realized by software or hardware clock.
Step S102, initializing a consensus system;
the method comprises the steps that related parameters of a consensus system are initialized and set before the first round of view conversion, in the practical Byzantine fault-tolerant consensus process, the number of requests continuously executed by the consensus nodes for determining stable CHECKPoint is included, namely after the consensus nodes execute the Nth request, the consensus nodes broadcast the other consensus nodes to inform the other consensus nodes that the N requests have achieved consistency results. N can be set to multiples of 100 and 100 according to common empirical values in the prior art. In addition, three parameters related to the waterline, namely a low waterline L, a waterline height K and a high waterline H, need to be set in the initialization process, wherein the low waterline L is normally set as the latest request number of stable CHECKPOINT, and the low waterline L is set as 0 during initialization; the height K of the waterline is also an empirical value, and according to the disclosure of the related documents, a value of 100, or 200, or 400 is usually selected, and the high waterline H is L + K, that is, the high waterline H is the sum of the low waterline L and the height K of the waterline.
In the consensus process, as the stable CHECKPoint continuously increases, the low waterline L also synchronously increases, and keeps a value equal to the latest stable CHECKPoint, and correspondingly, the high waterline H also synchronously increases on the basis of the waterline height K. In various embodiments of the present invention, the waterline height K is not fixed in the prior art, but rather varies as the consensus process progresses.
During system initialization, a waterline height timer TWMSet to 0 and begin timing after consensus starts.
Step S104, recording a first numerical value obtained when the ith view is converted;
recording the value T of a waterline height timer when the ith round of view is convertediTaking the first round as an example, the value of the waterline height timer when the first round view is converted is recorded. When the first round of view is converted, the height timer T of the waterline is recorded and storedWMValue of (A) T1While resetting the waterline height timer to 0, T at this time1The running period of the consensus system under the current machine performance and the network environment can be measured, and the height of the waterline is not adjusted according to the condition that the height of the waterline is not adjusted because no reference object is arranged when the first round view is converted, so that the height of the waterline is not changed.
In the process of view conversion, each consensus node may become a main consensus node, that is, the decentralized setting causes the parameters of the consensus system to be set in a broadcast form or in a consensus form. When the view is converted, the main common identification node is possibly down or disconnected, so that the common identification node for replacement has the capacity and the reserve for setting the common identification system parameters, and thereforeAccording to the situation that each common node is likely to become a main common node, each common node should have a waterline height timer TWM. It can be seen that, at the time of initialization of the consensus system, each consensus node should set the waterline height timer TWMSet to 0 and begin timing after consensus starts.
When the first round of view is changed, the view is changed not immediately but only after a certain time, so that the waterline height timer T needs to be determined during the process of view changeWMThe point in time of being reset and recorded. To determine this point in time, the time axis over which the view transitions needs to be analyzed. Firstly, a common node which discovers that a main common node is down or disconnected broadcasts and sends VIEW-CHANGE information to other common nodes in a common system, wherein the next VIEW and a new main common node are determined; secondly, each consensus node receives the VIEW-CHANGE message broadcast and sent by other consensus nodes, after a certain number of VIEW-CHANGE messages are received, the consensus system forms consensus on the next round of VIEW and a new main consensus node at the moment, and each consensus node sends an ACK message to the new main consensus node to indicate that the new main consensus node gives permission to exercise right in the new VIEW; and thirdly, after receiving a certain number of ACK messages, the NEW main consensus node broadcasts a NEW-VIEW message to each consensus node and starts to resend the Pre-Prepare message.
As can be seen from the timeline where the VIEW transitions, broadcast transmission VIEW-CHANGE message is the beginning of the timeline and broadcast transmission NEW-VIEW message is the end of the timeline, which may be candidate points in time for the watermark timer to be reset and recorded, either broadcast transmission VIEW-CHANGE message or broadcast transmission NEW-VIEW message as events that trigger the watermark timer. However, broadcasting the VIEW-CHANGE message does not guarantee that the next VIEW round with the new consensus node will be entered because the new consensus node may also be down or disconnected, requiring each of the consensus nodes to broadcast the VIEW-CHANGE message again, wherein the new VIEW round and the new consensus node are determined again. The consensus system repeats the above process until a normal NEW master consensus node broadcasts and sends a NEW-VIEW message, at which point, the VIEW transition is successfully completed.
According to the analysis and judgment, the time length of VIEW conversion can be accurately recorded only by taking broadcast sending NEW-VIEW information as an event for triggering the waterline height timer, so that when the main consensus node of the NEW VIEW sends the NEW-VIEW information to other consensus nodes, the main consensus node of the NEW VIEW records and stores the numerical value of the waterline height timer, resets the waterline height timer and starts the next round of timing; when other consensus nodes receive the NEW-VIEW message of the main consensus node, the consensus nodes record the numerical value of the waterline height timer, reset the waterline height timer and start the next round of timing.
Step S106, recording a second numerical value during the view conversion of the (i +1) th time;
recording the value T of a waterline height timer when the (i +1) th wheel view is convertedi+1
And taking the second wheel as an example, recording the waterline height timer value when the second wheel view is converted, and calculating the waterline height change setting value. When the second round view is converted, the height timer T of the waterline is recorded and storedWMValue of (A) T2While resetting the waterline height timer to 0, T at this time2The machine performance and the running period of the network environment of the consensus system between two transitions of views can be measured.
And step S108, calculating a new waterline height by the main consensus node after the (i +1) th view conversion according to the first numerical value, the second numerical value and a preset rule recorded during the view conversion, and broadcasting the new waterline height to other consensus nodes.
When the second round of views are converted, recording and storing a waterline height timer T when each round of views is convertedWMThe value of (A), T obtained by converting the view of the current roundiT obtained by converting the previous viewi-1After the weight is obtained, the weight is multiplied by the current waterline height to obtainAnd the new waterline height is used for circularly changing the set waterline height.
The T recorded in step S1041As a reference object, the current operating period T can be compared2Whether to lengthen or shorten can be used to express the change situation of the operation cycle by weight:
Figure BDA0002478533760000091
when the weight value muTWhen the weight value is more than 1, the running period of the current round is longer than that of the previous round, the current machine performance and network conditions can be reduced, and the time for completing the consensus work of the next round can be longer, so that the waterline height of the next round needs to be adjusted up, and conversely, when the weight value is muTIf the current machine performance and network conditions are improved, the time for completing the next round of consensus work is shorter than 1, the operation period of the current round is shorter than that of the previous round, and therefore the waterline height of the next round needs to be adjusted downwards. The specific calculation formula is as follows:
Figure BDA0002478533760000101
wherein, since the height of the current assembly line is not changed, K1The waterline height for the previous and current round is the same as the initialized value, and K2Will be taken as the next waterline height.
It should be noted that each consensus node may become a master consensus node, and although each consensus node has its own watermark timer, in order to save computing resources, only a new master consensus node needs to compute and determine a new watermark according to a result of the view conversion. In order to enable all the common identification nodes in the common identification system to execute the common identification process according to the new waterline height, after the set waterline height is updated, the new main common identification node also needs to broadcast and send the new waterline height to all the common identification nodes.
Example two
As shown in fig. 5, in addition to the time interval of view transition adopted in the above embodiment to characterize the machine performance and network environment of the consensus system or the consensus node, other parameters in the view transition process may also be used, for example, when the view transition occurs, the number of requests for the consensus node to perform the consensus process in different network environments is different; the consensus system is in a network environment for a long time, and cannot completely ensure that the consensus system is in a good network environment for a long time, for example, the consensus system is shielded, faded and subjected to electromagnetic interference in a wireless environment, and electrophoresis, electric arcs and other phenomena are generated in a wired environment; therefore, some of the consensus nodes process a larger number of requests because of the good network environment, and conversely some of the nodes process a smaller number of requests. In this case, the larger the network difference between different consensus nodes is, the more the difference between the number of executed requests between different consensus nodes is, and in order to avoid the consensus node with good network environment being in a state of frequently waiting, the pipeline height needs to be further adjusted, so as to provide more appropriate adjustment time for the consensus node with poor network environment, and improve the network environment. In order to completely represent the difference of execution requests among different consensus nodes as much as possible, extracting the minimum value of the request number of a stable CHECKPoint set in a VIEW-CHANGE message and the maximum value of the request number of a PREPARE message set in the VIEW-CHANGE message, and further obtaining the difference value delta between the minimum value of the request number and the maximum value of the request number, wherein the difference value delta represents the maximum value of the number of requests which are not executed in the consensus network and the value of the difference value delta can be influenced by the network environment, and therefore the difference value delta is used as another parameter of the waterline height CHANGE setting.
Step S202, initializing a consensus system;
similar to the embodiment, in this step, the initial setting of the relevant parameters of the consensus system is performed, and each time the parameter N of the stable CHECKPOINT is reached, the initial setting may also be set to be a multiple of 100 and 100 according to the empirical value. With the low waterline L of the relevant three parameter of waterline, waterline height K, high waterline H when the initialization, do the following setting equally: the low waterline L is set to be 0, the waterline height K selects values of 100, 200 or 400 and the like according to empirical values, and the high waterline H is the sum of the low waterline L and the waterline height K. During system initialization, the difference Δ is set to 0.
In the consensus process, as the stable CHECKPoint continuously increases, the low waterline L also synchronously increases, and keeps a value equal to the latest stable CHECKPoint, correspondingly, the high waterline H also synchronously increases on the basis of the waterline height K, and the waterline height K continuously changes along with the development of the consensus process.
Step S204, recording a first numerical value obtained when the ith view is converted;
recording and calculating the difference value delta when the ith round of view is convertediI.e. the first value, i is a positive integer, taking the first round as an example, when the first round is converted, the first round difference value delta is recorded and stored1At this time,. DELTA.1The difference degree of the network environment among the current common identification nodes can be reflected to a certain degree, and the waterline height is not adjusted according to the reference object when the first round view is converted, so that the waterline height is not changed at the moment.
The difference value Delta1According to the analysis of the first embodiment, it is possible that each consensus node becomes a main consensus node during the view transition. Each consensus node sends or receives a VIEW-CHANGE message carrying a stable chekpoint, and a certain number of chekpoint messages received from other consensus nodes to indicate that the stable chekpoint is known, and the VIEW-CHANGE message carries a request for all PREPARE messages on the stable chekpoint.
Therefore, each consensus node will receive the VIEW-CHANGE messages of other consensus nodes, i.e. the stable checksum on other consensus nodes, and all PREPARE messages, in addition to the stable checksum on its own node, and all PREPARE messages. That is, each consensus node can independently calculate the current VIEW-CHANGE message according to the consensus node and the received informationAnd extracting the maximum value of the request number of the PREPARE message set in the VIEW-CHANGE message, namely the difference value deltaiAnd stored on each consensus node.
Step S206, recording a second numerical value during the view conversion of the (i +1) th time;
recording and calculating the difference value delta when the (i +1) th round view is convertedi+1The value of the second value, i.e.,
taking the example of the second round conversion, when the second round view is converted, the second round difference value delta is recorded and calculated and stored2。
And step S208, calculating a new waterline height by the main common identification node after the (i +1) th view conversion according to the first numerical value, the second numerical value and a preset rule recorded during the view conversion, and broadcasting the new waterline height to other common identification nodes.
After the second round of VIEWs are converted, when each round of VIEWs is converted, each consensus node records and calculates the minimum value of the request number of the stable CHECKOINT set in the current VIEW-CHANGE message and the difference delta between the maximum values of the request numbers of the PREPARE message sets in the VIEW-CHANGE message, and the delta obtained by converting the VIEWs in the current round is extractedi+1Except delta converted from the previous viewiAnd after the weight is obtained, multiplying the weight by the current waterline height to obtain a new waterline height, and starting to circularly change the set waterline height K.
Converting the Δ recorded in step S2041As a reference object, whether the current network environment is improved or reduced can be compared, and the change condition of the operation cycle can be represented by a weight value:
Figure BDA0002478533760000111
when the weight value muΔWhen the number of the requests is larger than 1, the difference between the number of the requests of different consensus nodes in the current round is enlarged, which indicates that the current network condition may be reduced, and a longer time may be required for completing the consensus operation of the next roundDo so, therefore, the waterline height of the next round needs to be adjusted up, and conversely, when the weight μΔWhen the number difference of the requests between different consensus nodes in the current round is smaller than 1, the current network condition may be improved, and a shorter time may be required to complete the next round of consensus, so that the height of the waterline in the next round needs to be adjusted downward. The specific calculation formula is as follows:
Figure BDA0002478533760000121
wherein, since the height of the current assembly line is not changed, K1The waterline height for the previous and current round is the same as the initialized value, and K2Will be used as the next waterline height
Similar to the embodiment, in order to enable all the consensus nodes in the consensus system to perform the consensus process according to the new waterline height, after the set waterline height is updated, the new master consensus node further needs to broadcast and send the new waterline height to all the consensus nodes.
EXAMPLE III
As shown in fig. 6, in this embodiment, based on the second embodiment, the request that has completed the consensus process once is deleted according to the actual situation that each consensus node executes the request, wherein the specific basis for changing the set waterline height is substantially the same as the second embodiment, that is, the minimum request number of the stable CHECKPOINT set in the VIEW-CHANGE message is still extracted, and the maximum request number of the PREPARE message set in the VIEW-CHANGE message is extracted, so as to obtain the difference Δ between the minimum request number and the maximum request number. However, not all requests do not complete the consensus once between the above request number minimum and the request number maximum, some of which have entered the COMMIT phase, and therefore there is no PREPARE message set in the VIEW-CHANGE message, which does not belong to a request of the three-phase consensus process that is currently still being performed.
FIG. 7 is a schematic diagram showing a correction principle, wherein the progress of each consensus node is inconsistent, the minimum value of the request numbers in the stable CHECKPoint set in the VIEW-CHANGE message is selected as the leftmost base line, the maximum value of the request numbers in the PREPARE message set in the VIEW-CHANGE message is selected as the rightmost base line, the gray part is the request without the PREPARE message set, and in the NEW VIEW, in order to ensure the sequential execution, the part of the request without the PREPARE message set still enters the NEW-VIEW message, but is endowed with a NULL value.
Since the time consumption of the part of the request to the consensus node is small, the part of the request should not participate in measuring the actual working condition of the consensus system. According to the above analysis, the request number α without the PREPARE message set between the request number maximum and the request number minimum is counted, and the request number α without the PREPARE message set is subtracted from the difference Δ between the request number minimum and the request number maximum to obtain δ ═ Δ - α.
The value δ reflects the number of requests that actually do not substantially reach the consensus state in the previous view, and may be more capable of characterizing the current consensus system as affected by the network environment, so that the value δ Δ - α is used as another parameter of the waterline height change setting, where the value δ becomes the corrected difference δ.
Step S302, initializing a consensus system;
similar to the previous embodiment, in this step, the initial setting of the relevant parameters of the consensus system is performed, and each time the parameter N of the stable CHECKPOINT is reached, the initial setting may also be set to be a multiple of 100 and 100 according to the empirical value. With the low waterline L of the relevant three parameter of waterline, waterline height K, high waterline H when the initialization, do the following setting equally: the low waterline L is set to be 0, the waterline height K selects values of 100, 200 or 400 and the like according to empirical values, and the high waterline H is the sum of the low waterline L and the waterline height K. During system initialization, the corrected difference δ is set to 0.
In the consensus process, as the stable CHECKPoint continuously increases, the low waterline L also synchronously increases, and keeps a value equal to the latest stable CHECKPoint, correspondingly, the high waterline H also synchronously increases on the basis of the waterline height K, and the waterline height K continuously changes along with the development of the consensus process.
Step S304, recording a first numerical value obtained when the ith view is converted;
recording and calculating the corrected difference value delta when the ith round of view is convertedi；
Taking the first round conversion example, when the first round view is converted, the first round difference value delta is recorded1And extracting the request number alpha without PREPARE set from the request number1From the first round by a difference Δ1Minus alpha1Obtaining and storing delta1＝Δ1-α1. At this time delta1The difference degree of the network environment among the current common identification nodes can be reflected to a certain degree, and the waterline height is not adjusted according to the reference object when the first round view is converted, so that the waterline height is not changed at the moment.
Step S306, recording a second numerical value during the view conversion of the (i +1) th time;
recording and calculating the corrected difference value delta when the (i +1) th round view is convertedi+1. Taking the example of the second wheel conversion, when the second wheel view is converted, the corrected difference value delta is obtained2。
And step S308, calculating a new waterline height by the main consensus node after the (i +1) th view conversion according to the first numerical value, the second numerical value and a preset rule recorded during the view conversion, and broadcasting the new waterline height to other consensus nodes.
When each round of VIEW is converted, each consensus node records and calculates the difference value delta between the minimum value of the request number of the stable CHECKPoint set in the current VIEW-CHANGE message and the maximum value of the request number of the PREPARE message set in the extracted VIEW-CHANGE message, subtracts the request number alpha without the PREPARE set, and converts the VIEW in the current round into deltai+1Except delta obtained by converting the previous viewiAfter the weight is obtained, the weight is multiplied by the current waterline height to obtain a new waterline height, and the set waterline is changed circularly according to the new waterline heightA height K.
Specifically, δ recorded in step S3041As a reference object, whether the current network environment is improved or reduced can be compared, and the change condition of the operation cycle can be represented by a weight value:
Figure BDA0002478533760000131
when the weight value muδWhen the current network condition is more than 1, the quantity difference of the requests among different consensus nodes in the current round is enlarged, which indicates that the current network condition may be reduced, and a longer time may be needed to complete the next round of consensus work, therefore, the height of the waterline in the next round needs to be adjusted up, and conversely, when the weight value mu is greater thanδWhen the number difference of the requests between different consensus nodes in the current round is smaller than 1, the current network condition may be improved, and a shorter time may be required to complete the next round of consensus, so that the height of the waterline in the next round needs to be adjusted downward. The specific calculation formula is as follows:
Figure BDA0002478533760000132
wherein, since the height of the current assembly line is not changed, K1The waterline height for the previous and current round is the same as the initialized value, and K2Will be taken as the next waterline height.
Similar to the above embodiment, in order to enable all the consensus nodes in the consensus system to perform the consensus process according to the new waterline height, after the set waterline height is updated, the new master consensus node further needs to broadcast and send the new waterline height to all the consensus nodes.
Example four
In order to further improve the modification stability of the waterline height and more fully consider the situation of the comprehensive action of various factors, the embodiment comprehensively considers the time interval between the view generation and conversion, the request set needing to be processed in the view generation and conversion process, and the request set without PREPARE message in the request set. The three factors are integrated, and the height of the waterline can be further and reasonably changed.
In this embodiment, each consensus node is provided with a waterline height timer TWMCalculating the difference value delta between the minimum value of the request numbers of the stable CHECKOINT set in the current VIEW-CHANGE message and the maximum value of the request numbers of the PREPARE message set in the VIEW-CHANGE message, and subtracting the request number alpha without the PREPARE set.
Step S402, initializing a consensus system;
similar to the previous embodiment, in this step, the initial setting of the relevant parameters of the consensus system is performed, and each time the parameter N of the stable CHECKPOINT is reached, the initial setting may also be set to be a multiple of 100 and 100 according to the empirical value. With the low waterline L of the relevant three parameter of waterline, waterline height K, high waterline H when the initialization, do the following setting equally: the low waterline L is set to be 0, the waterline height K selects values of 100, 200 or 400 and the like according to empirical values, and the high waterline H is the sum of the low waterline L and the waterline height K. During system initialization, a waterline height timer TWMSet to 0, the difference Δ to 0, and the corrected difference δ to 0.
In the consensus process, as the stable CHECKPoint continuously increases, the low waterline L also synchronously increases, and keeps a value equal to the latest stable CHECKPoint, and correspondingly, the high waterline H also synchronously increases on the basis of the waterline height K. In various embodiments of the present invention, the waterline height K is not fixed in the prior art, but rather varies as the consensus process progresses.
Step S404, recording and calculating the value T of the waterline height timer when the ith wheel view is convertediDifference value deltaiCorrected difference value deltai。
Taking the first round of view conversion as an example, when the first round of view is converted, the waterline height timer T is recordedWMValue of (A) T1Simultaneously resetting the waterline height timer to 0 while aggregating according to the stable CHECKPoint in the VIEW-CHANGE messageAnd extracting the maximum value of the request number of the PREPARE message set in the VIEW-CHANGE message, and calculating the first round difference value delta1And further extracts the number of requests alpha without PREPARE sets1From the first round by a difference Δ1Minus alpha1To obtain delta1＝Δ1-α1. Because there is no reference object when the first round view is converted, there is no basis for adjusting the height of the waterline, and the setting of the waterline height is not changed at this time.
Step S406, recording the value T of the waterline height timer when the (i +1) th round view is convertedi+1Difference value deltai+1Corrected difference value deltai+1。
Taking the second round of view conversion as an example, when the second round of view is converted, the waterline height timer T is recordedWMValue of (A) T2While simultaneously resetting the waterline height timer to 0 and recording and calculating a second round difference value delta2And the corrected difference value delta2。
Step S408, calculating a new waterline height by the main consensus node after the (i +1) th view conversion according to the first numerical value, the second numerical value and a preset rule recorded during the view conversion, and broadcasting the new waterline height to other consensus nodes.
When each round of view is converted, the three numerical values are recorded and calculated, the three numerical values obtained by conversion of the previous round of view are combined to obtain a weight, a comprehensive weight is obtained through arrangement, combination or function use, the comprehensive weight is multiplied by the current waterline height to obtain a new waterline height, and the set waterline height is changed circularly.
At this time, three available parameters are used as the basis for changing the set waterline height, and the three available parameters can be arranged, combined or used in various ways. Limited examples will be given in this embodiment, but actually, it will not be limited to these examples.
In the first embodiment, three parameters T, Δ, and δ are simultaneously referred to, and the weight is set in a product manner, which is as follows:
Figure BDA0002478533760000151
the specific calculation formula for the waterline height change setting is as follows:
Figure BDA0002478533760000152
and example two, the weight is set by taking the maximum value by referring to two parameters. For example, the largest weight is selected as the reference weight from the weights based on the waterline height timer T and the weight based on the difference Δ, which is as follows:
Figure BDA0002478533760000153
the specific calculation formula for the waterline height change setting is as follows:
Figure BDA0002478533760000154
the maximum weight value can be selected as a reference weight value from the weight value based on the waterline height timer T and the weight value based on the corrected difference value δ, which is as follows:
Figure BDA0002478533760000155
the specific calculation formula for the waterline height change setting is as follows:
Figure BDA0002478533760000156
wherein, since the height of the current assembly line is not changed, K1The waterline height for the previous and current round is the same as the initialized value, and K2Will be taken as the next waterline height.
It should be noted that each consensus node may become a master consensus node, and although each consensus node has its own watermark timer, in order to save computing resources, only a new master consensus node needs to compute and determine a new watermark according to a result of the view conversion. In order to enable all the common identification nodes in the common identification system to execute the common identification process according to the new waterline height, after the waterline height is updated and set, the new main common identification node also needs to broadcast the new waterline height to all the common identification nodes and send the new waterline height.
The embodiments mentioned in the present specification are only used for illustrating the technical solutions, not for limiting the protection scope, and although the technical solutions of the present invention are described in detail with reference to the embodiments, those skilled in the art should understand that the technical solutions of the embodiments can be further modified, improved, or some or all of the technical features can be replaced; and that such modifications, improvements or substitutions do not materially depart from the scope of the invention as intended.

Claims (10)

1. A method for changing and setting the height of a waterline is characterized in that,
recording to obtain a first numerical value during view conversion of the ith time and a second numerical value during view conversion of the (i +1) th time, wherein i is a positive integer;
calculating a new waterline height by the main consensus node after the (i +1) th view conversion according to the first numerical value, the second numerical value and a preset rule recorded during the view conversion, and broadcasting the new waterline height to other consensus nodes;
wherein, the first value or the second value in view conversion at least comprises one of the following values: the method comprises the steps that a waterline height timer value when a view is converted, the maximum value of the number of requests which are not executed and completed in a consensus network and the number of requests which actually do not reach a consensus state in the previous view are obtained;
when the first value or the second value recorded during view conversion comprises a waterline height timer value, each consensus node starts timing by the waterline height timer after consensus starts, and when the view conversion occurs, the value of the waterline height timer is recorded and the waterline height timer is reset.
2. The waterline level change setting method of claim 1,
the first numerical value is the value of a waterline height timer during the ith view conversion;
the second value is the value of a waterline height timer during the (i +1) th view conversion;
and calculating and determining a new waterline height by the main common recognition node after the (i +1) th view conversion according to the first numerical value and the second numerical value by using a preset rule, and broadcasting the new waterline height to other common recognition nodes.
3. The waterline level change setting method of claim 1,
the first value is the difference value between the minimum value of the request numbers in the stable CHECKPoint set in the VIEW-CHANGE message and the maximum value of the request numbers in the PREPARE message set during the ith VIEW conversion; the second value is the difference value between the minimum value of the request numbers in the stable CHECKPoint set in the VIEW-CHANGE message and the maximum value of the request numbers in the PREPARE message set during the VIEW conversion of the (i +1) th time;
and calculating and determining a new waterline height by the main common recognition node after the (i +1) th view conversion according to the first numerical value and the second numerical value by using a preset rule, and broadcasting the new waterline height to other common recognition nodes.
4. The waterline level change setting method of claim 3,
counting the number of requests without a PREPARE message set between the maximum value of the request number and the minimum value of the request number during the ith view conversion, subtracting the number of requests without the PREPARE message set from the first value, and taking the value obtained after subtraction as a corrected first value;
counting the number of requests without a PREPARE message set between the maximum value of the request number and the minimum value of the request number during the view conversion of the (i +1) th time, subtracting the number of requests without the PREPARE message set from the second value, and taking the value obtained after subtraction as a corrected second value;
and calculating and determining a new waterline height by the main common recognition node after the (i +1) th view conversion according to the corrected first numerical value and the corrected second numerical value by using a preset rule, and broadcasting the new waterline height to other common recognition nodes.
5. The waterline level change setting method of claim 1,
the recorded first value at least comprises one of a value of a water-level timer at the time of the ith VIEW transition, a difference value between the minimum value of the request number in the stable CHECKPoint set in the VIEW-CHANGE message and the maximum value of the request number in the PREPARE message set, and a value obtained by subtracting the number of requests without the PREPARE message set between the maximum value of the request number and the minimum value of the request number from the difference value between the minimum value of the request number in the stable CHECKPoint set in the VIEW-CHANGE message and the maximum value of the request number in the PREPARE message set;
the second value of the record at least comprises one of a value of a waterline height timer at the time of the i +1 th VIEW transition, a difference value between the minimum value of the request numbers in the stable CHECKPoint set in the VIEW-CHANGE message and the maximum value of the request numbers in the PREPARE message set, and a value obtained by subtracting the request number without the PREPARE message set between the maximum value of the request numbers and the minimum value of the request numbers from the difference value between the minimum value of the request numbers in the stable CHECKPoint set in the VIEW-CHANGE message and the maximum value of the request numbers in the PREPARE message set;
and calculating the new waterline height by the main consensus node after the (i +1) th view conversion according to the recorded first numerical value and second numerical value by using the preset rule.
6. The waterline height change setting method of any one of claims 1-5, wherein the preset rule is that a quotient obtained by dividing a second numerical value obtained by the i +1 th view conversion by a first numerical value obtained by the i th view conversion is used as a weight, and the weight is multiplied by the waterline height after the i th view conversion to obtain a new waterline height.
7. The waterline height change setting method of claim 6, wherein the preset rule is that a quotient obtained by dividing a second value recorded by the (i +1) th view conversion by a first value recorded by the (i) th view conversion is used as a weight, and the weight is multiplied by the waterline height at the i th view conversion to obtain a new waterline height;
if the recorded numerical value is a waterline height timer numerical value, the first weight is the waterline height timer numerical value in the (i +1) th view conversion divided by the waterline height timer numerical value in the ith view conversion;
if the recorded numerical value is the difference between the minimum value of the request numbers in the stable CHECKOINT set in the VIEW-CHANGE message and the maximum value of the request numbers in the PREPARE message set, the second weight value is the difference between the minimum value of the request numbers in the stable CHECKOINT set in the VIEW-CHANGE message and the maximum value of the request numbers in the PREPARE message set at the i +1 th VIEW conversion time, and is divided by the difference between the minimum value of the request numbers in the stable CHECKOINT set in the VIEW-CHANGE message and the maximum value of the request numbers in the PREPARE message set at the i th VIEW conversion time;
if the recorded value is the value obtained by subtracting the number of requests without PREPARE message set between the maximum value of the request number and the minimum value of the request number from the difference between the minimum value of the request number in the stable CHECKOINT set in the VIEW-CHANGE message and the maximum value of the request number in the PREPARE message set, the third weight is the value obtained by subtracting the number of requests without prefix message set between the maximum value of the request number and the maximum value of the request number in the prefix message set from the difference between the minimum value of the request number in the stable checksum point set in the VIEW-CHANGE message at the i +1 th VIEW transition by subtracting the number of requests without prefix message set between the maximum value of the request number and the maximum value of the request number in the stable checksum point set in the VIEW-CHANGE message at the i th VIEW transition by subtracting the number of requests without prefix message set between the maximum value of the request number and the minimum value of the request number; and calculating a new waterline height according to at least two of the weights.
8. The method of claim 7, wherein the new waterline height is obtained by taking the maximum value of the first weight, the second weight, the third weight, or the maximum value between two of the first weight, the second weight, and the third weight, and multiplying the maximum value by the current waterline height.
9. The waterline height change setting method of claim 1, wherein the initial value of the waterline height at the time of the first start consensus is an empirical value.
10. The waterline height change setting method of claim 2, wherein after the consensus is initiated, if i is 1, when the view transitions, the waterline height timer value is recorded and the waterline height timer is reset without any change setting for the waterline height.
CN202010375633.6A 2020-05-06 2020-05-06 Waterline height changing and setting method Active CN111586168B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010375633.6A CN111586168B (en) 2020-05-06 2020-05-06 Waterline height changing and setting method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010375633.6A CN111586168B (en) 2020-05-06 2020-05-06 Waterline height changing and setting method

Publications (2)

Publication Number Publication Date
CN111586168A CN111586168A (en) 2020-08-25
CN111586168B true CN111586168B (en) 2022-04-08

Family

ID=72112040

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010375633.6A Active CN111586168B (en) 2020-05-06 2020-05-06 Waterline height changing and setting method

Country Status (1)

Country Link
CN (1) CN111586168B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112068978B (en) * 2020-08-27 2022-06-10 恒宝股份有限公司 Method and device for prolonging timing period of VIEW-CHANGE secondary start timer

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9035957B1 (en) * 2007-08-15 2015-05-19 Nvidia Corporation Pipeline debug statistics system and method
CN107967597A (en) * 2017-11-28 2018-04-27 中国工商银行股份有限公司 Electronic identification processing, storage method and device and electronic identification processing system
CN109993647A (en) * 2019-03-08 2019-07-09 西安电子科技大学 A kind of pay taxes credit investigation system and processing method based on block chain
CN110555129A (en) * 2019-08-16 2019-12-10 桂林电子科技大学 space image data interaction method and device based on alliance chain
CN110784461A (en) * 2019-10-23 2020-02-11 北方工业大学 Safe 6LoWPAN communication method and system based on block chain
CN110880143A (en) * 2018-09-05 2020-03-13 阿克塞勒公司 System and method for processing transaction verification operations in decentralized applications
CN110943838A (en) * 2018-09-21 2020-03-31 上海派链信息科技有限公司 Method, apparatus and storage medium for determining consensus of blocks in a blockchain network

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10425348B2 (en) * 2015-07-22 2019-09-24 The Regents Of The University Of Colorado Stateless network functions
US10033702B2 (en) * 2015-08-05 2018-07-24 Intralinks, Inc. Systems and methods of secure data exchange
CN109685505B (en) * 2018-12-24 2020-09-22 电子科技大学 Byzantine fault-tolerant consensus optimization method based on association ring signature
CN110677485B (en) * 2019-09-30 2020-11-13 大连理工大学 Dynamic layered Byzantine fault-tolerant consensus method based on credit

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9035957B1 (en) * 2007-08-15 2015-05-19 Nvidia Corporation Pipeline debug statistics system and method
CN107967597A (en) * 2017-11-28 2018-04-27 中国工商银行股份有限公司 Electronic identification processing, storage method and device and electronic identification processing system
CN110880143A (en) * 2018-09-05 2020-03-13 阿克塞勒公司 System and method for processing transaction verification operations in decentralized applications
CN110943838A (en) * 2018-09-21 2020-03-31 上海派链信息科技有限公司 Method, apparatus and storage medium for determining consensus of blocks in a blockchain network
CN109993647A (en) * 2019-03-08 2019-07-09 西安电子科技大学 A kind of pay taxes credit investigation system and processing method based on block chain
CN110555129A (en) * 2019-08-16 2019-12-10 桂林电子科技大学 space image data interaction method and device based on alliance chain
CN110784461A (en) * 2019-10-23 2020-02-11 北方工业大学 Safe 6LoWPAN communication method and system based on block chain

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
Research on Optimization Model of Storage Capacity Based on the Consortium Blockchain. The International Conference on Communications;Xiaotian Wei, Jiahua Chen, Zhihuai Li;《International Conference in Communications, Signal Processing, and Systems》;20190614;全文 *
一种区块链实用拜占庭容错算法的改进;韩镇阳,宫宁生,任珈民;《计算机应用与软件》;20200212;第37卷(第02期);全文 *
一种改进PBFT算法作为以太坊共识机制的研究与实现;黄秋波,安庆文,苏厚勤;《计算机应用与软件》;20171015;第34卷(第10期);全文 *

Also Published As

Publication number Publication date
CN111586168A (en) 2020-08-25

Similar Documents

Publication Publication Date Title
CN106484528B (en) For realizing the method and device of cluster dynamic retractility in Distributed Architecture
JP5815512B2 (en) Resource management method, computer system, and program
CN111586168B (en) Waterline height changing and setting method
KR20100122858A (en) Computer readable recording medium, job scheduling apparatus and job scheduling method
CN113434253B (en) Cluster resource scheduling method, device, equipment and storage medium
CN110554732A (en) identification number generation method and device, electronic equipment and storage medium
JP2012079242A (en) Composite event distribution device, composite event distribution method and composite event distribution program
CN108983946B (en) Server power consumption control method, system and equipment
CN114500355B (en) Routing method, network-on-chip, routing node and routing device
CN115102839A (en) Master-slave node election method, device, equipment and medium
CN112954009A (en) Block chain consensus method, device and storage medium
CN112486642A (en) Resource scheduling method and device, electronic equipment and computer readable storage medium
CN115617520A (en) Resource parameter configuration method and device, electronic equipment and storage medium
JP2019086949A (en) Information processing device, information processing system, and program
CN112468573B (en) Data pushing method, device, equipment and storage medium based on distributed deployment
CN113302593A (en) Task processing method, device and system, electronic equipment and storage medium
JP2010198204A (en) Clustering server system and data transfer method
JPH07152699A (en) Method, device and system for information processing
CN109450818B (en) Method, device, equipment and medium for issuing information of Internet of things
CN113284039A (en) Bitmap management method, device and equipment and readable storage medium
CN114756324A (en) Computing power resource allocation method, device, equipment and medium
CN111176814A (en) Task execution method and related device
JPWO2014167768A1 (en) Frequency control method and frequency control system
CN112148793B (en) Data synchronization method, system and storage medium
CN110795204A (en) Virtual machine deployment method and device

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
CB03 Change of inventor or designer information
CB03 Change of inventor or designer information

Inventor after: Qian Jing

Inventor after: Cui Ke

Inventor after: Li Wan

Inventor before: Qian Jing

Inventor before: Li Wan

Inventor before: Cui Ke

GR01 Patent grant
GR01 Patent grant