Method and system for recovering fault node of asynchronous block chain system

Abstract

The invention discloses a method and a system for recovering fault nodes of an asynchronous block chain system, and belongs to the technical field of block chain networks. In order to solve the problem of node state lagging caused by equipment failure, network fluctuation or hostile attack in an asynchronous block chain system, a reference height value and a parallelized state recording, state updating and protocol execution module are introduced, so that quick synchronization and recovery of a failure node are realized. The main technical means adopted by the invention comprise an information verification mechanism based on node consistency and a modular parallel processing architecture, so as to ensure data consistency and efficient recovery. According to the method, the safety, recovery efficiency, adaptability and expansibility of the system are improved, and effective recovery of the fault nodes and the overall stability and reliability of the system are ensured.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain network technology, and in particular to a method and system for recovering failed nodes of an asynchronous blockchain system. Background Art

[0002] Blockchain technology refers to a technical solution that ensures that all participants jointly maintain a distributed ledger through a consensus mechanism. According to different network model assumptions, it can be further divided into three types: synchronous, semi-synchronous and asynchronous, among which asynchronous is the weakest assumption. In the asynchronous network model assumption, neither the participants nor the designer can obtain the upper bound of the network delay, which makes the asynchronous blockchain consensus more complicated in design. In a blockchain system, due to equipment failure, network fluctuations, malicious attacks by adversaries, etc., the internal state of some honest nodes will lag behind other nodes. This will cause the lagging nodes to be unable to directly participate in the generation of the latest blocks, and even threaten the security of the system. For blockchain systems based on synchronous and semi-synchronous network assumptions, lagging nodes can use the system synchronization time period to efficiently synchronize their states. For blockchain systems based on asynchronous network assumptions, a general recovery mechanism is still needed to help lagging nodes synchronize their states. Summary of the invention

[0003] The purpose of the present invention is to solve the problem of fault node recovery in the existing asynchronous blockchain system, and provide a method and system for recovering fault nodes in an asynchronous blockchain system.

[0004] The present invention adopts the following technical scheme to achieve its purpose:

[0005] A method for recovering a failed node in an asynchronous blockchain system comprises the following steps:

[0006] 1) Receive messages from other nodes in the asynchronous blockchain system except the currently failed node;

[0007] 2) If the target of the message is not a status update, then update the locally stored height value according to the node identity and height value contained in the message; and determine whether the message requires a status value of a certain height value. If so, check whether there is a status value of the corresponding height value locally and return it;

[0008] 3) Get the updated height value h new and the height value h of the current faulty node before the fault old , and get h from all other nodes old and h new The status value of the height value between is recorded locally;

[0009] 4) If the target of the message is a state update, the local state is updated according to the relationship between the height value and the corresponding state value contained in the message and the height value and the corresponding state value stored locally, the state value related to the blockchain is updated according to the number of locally updated state values, and the blockchain protocol is executed.

[0010] Furthermore, the height value stored locally in step 2) includes a height set H and a reference height value ht, where H contains n-1 elements, corresponding to the maximum height value contained in the message sent by each other node; n is the number of nodes in the system; ht is the nfth largest height value in the set H, and f is the number of faulty nodes tolerated by the asynchronous blockchain system.

[0011] Furthermore, the step of updating the locally stored height value according to the node identity and height value contained in the message in step 2) includes: for the node identity contained in the message, comparing the height value contained in the message with the height value of the node stored locally; if the height value contained in the message is greater than the height value of the node stored locally, updating the height value of the node stored locally to the height value contained in the message.

[0012] Furthermore, when the locally stored height value is updated in step 2), it is checked whether the ht value needs to be updated; if the ht value is greater than the local maximum height value h new , then h new Update to ht value and use it as the updated height value h in step 3) new .

[0013] Further, in step 4), the step of updating the local state according to the relationship between the height value and the corresponding state value contained in the message and the height value and the corresponding state value stored locally includes: for the node identity contained in the message, determining whether the height value contained in the message is within h old and h new If, and the status value corresponding to the height value contained in the message has not been stored locally, the status value corresponding to the height value contained in the message is updated locally.

[0014] Furthermore, in step 4), the method for updating the state value related to the blockchain according to the number of locally updated state values ​​is as follows: if f+1 identical state values ​​about the same height value are received locally from different nodes, the state value related to the blockchain is updated, where f is the number of faulty nodes tolerated by the asynchronous blockchain system.

[0015] A recovery system for a failed node in an asynchronous blockchain system, comprising:

[0016] The state recording module is used to receive messages from other nodes in the asynchronous blockchain system except the current faulty node, and determine whether the message is sent to the state update module. If so, it is directly forwarded, otherwise the message is forwarded to the protocol execution module, and the local height value is updated according to the node identity and height value contained in the message. The local height value includes the height set H and the reference height value ht; check whether the ht value needs to be updated. If it needs to be updated, the updated ht value is sent to the state update module and the protocol execution module;

[0017] The status update module is used to obtain the ht value from the status recording module and update the height value h new , obtain the height value h of the faulty node before the fault through the protocol execution module old and obtain from all other nodes the values ​​between h old and h new The state value corresponding to the height value between is stored locally; a message whose target is state update is obtained from the state recording module, and the local state is updated according to the relationship between the height value and the corresponding state value contained in the message and the local height value and the corresponding state value, and the update result is sent to the protocol execution module;

[0018] The protocol execution module is used to update the local maximum height value according to the ht value sent by the status recording module; determine whether the message sent by the status recording module requests a status value of a certain height value, and if so, check whether the local status value has a corresponding height value and return it; update the status value related to the blockchain according to the update result sent by the status update module, and execute the blockchain protocol.

[0019] Furthermore, the state recording module maintains an internal state set {H, ht}, where H contains n-1 elements, corresponding to the maximum height value contained in the message sent by each other node; ht is the nf-th highest value in the set H, and f is the number of faulty nodes tolerated by the asynchronous blockchain system.

[0020] Furthermore, the state update module maintains an internal state set {h old ,h new ,T,S}, where h old is the height value of the current faulty node before the fault, h new is the maximum ht value sent by the status recording module, T is h old and h new is the set of height values ​​between them, and S is the set of state values ​​corresponding to the height values ​​in set T obtained from other nodes.

[0021] Furthermore, the protocol execution module maintains an internal state set {h old ,ht,ST}, where h oldis the height value of the current faulty node before the fault, ht is the nf-th highest value in the set H, f is the number of faulty nodes tolerated by the asynchronous blockchain system, and ST is the set of all states related to the blockchain.

[0022] Furthermore, if the message received by the protocol execution module is not a state value request, the message is temporarily cached.

[0023] The present invention has achieved the following beneficial effects:

[0024] 1. The fault-tolerant height value ensures system security and fault-tolerant capability: The present invention introduces the fault-tolerant height value ht, so that even if there are up to f malicious nodes, the system can still provide an effective height threshold to help the faulty node synchronize to a state close to the latest state. This design ensures the security and reliability of the system when malicious behavior or equipment failure occurs, and reduces the potential risks of the system caused by the existence of faulty nodes.

[0025] 2. Modular parallel processing accelerates recovery efficiency: The present invention adopts a parallel processing architecture of state recording, state updating and protocol execution modules, so that the faulty node can quickly obtain the latest state information and synchronize to the latest state, and reconnect to other nodes in time during the recovery process. This parallel mechanism significantly improves the recovery efficiency of the system and ensures that the node re-participates in the normal operation of the system in the shortest time.

[0026] 3. Guarantee the consistency of state information: The present invention obtains high-level state information from multiple nodes and requires at least f+1 identical state values ​​when updating the state, thereby avoiding the data consistency problem caused by erroneous information from a single node. This design ensures data reliability during the recovery process and prevents the risk of state failure caused by erroneous data transmitted by individual nodes.

[0027] 4. Module independence and parallel design improve system adaptability: Each module in the present invention is independent and supports parallel execution, which can flexibly respond to different network conditions and various fault conditions. This architecture design not only improves the adaptability of the system under complex network conditions, but also enhances the scalability of the system, so that the system can maintain stable recovery performance when the scale is expanded or the network environment changes.

[0028] 5. Re-participation of failed nodes ensures overall system stability: The fault recovery mechanism of the present invention enables failed nodes to quickly and reliably recover to the latest state and re-participate in the blockchain consensus protocol, thereby maintaining the stability and consistency of the entire blockchain network. Even in the event of multiple node failures, the system can still maintain an effective consensus process, avoiding network forks or data inconsistencies.

[0029] 6. Efficient and secure asynchronous blockchain fault handling solution: This invention not only greatly improves the fault handling capability of the asynchronous blockchain system, but also achieves safe and reliable state synchronization by designing an efficient state recovery mechanism. This solution can effectively restore node states in asynchronous networks without the need for synchronized clocks, providing a practical solution for the implementation of efficient and secure blockchain systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 An architecture diagram of a recovery system for a failed node in an asynchronous blockchain system is shown;

[0031] Figure 2 A schematic diagram of the process of the status recording module is shown;

[0032] Figure 3 A schematic diagram of the process of the status update module is shown;

[0033] Figure 4 A schematic diagram of the flow of the protocol execution module is shown. DETAILED DESCRIPTION

[0034] To make the objectives, technical solutions and advantages of the embodiments of the present invention more clear, the embodiments of the present invention and the accompanying drawings are described in detail below.

[0035] The embodiment of the present invention specifically discloses a method and system for recovering a faulty node in an asynchronous blockchain system, the system comprising a state recording module, a state updating module and a protocol execution module, and the method and system execute the same processing steps. It should be noted that the faulty node mentioned in the present invention refers to a participant in the blockchain system whose state lags behind the latest state of the system due to equipment failure, network fluctuation, malicious attack by an adversary or other reasons. The height mentioned in the present invention can be a logically sequential sequence of sequence numbers such as the sequence number of a block, the sequence number of a consensus protocol, the sequence number of a self-protocol within a consensus protocol, etc. The blockchain system described in the present invention includes n participants, of which there are at most f malicious participants.

[0036] The present invention is applicable to a general asynchronous blockchain system. In the following embodiments, it is assumed that the system has n participants, of which at most f participants are malicious participants. The implementation of the technical solution of the present invention is described below by taking the recovery process of the faulty node Pi as an example.

[0037] 1. Initialization

[0038] Node Pi participates in the asynchronous blockchain system execution and fails at a certain moment. After troubleshooting, node Pi restores the connection with other nodes in the system.

[0039] 2. Fault recovery

[0040] Node Pi activates the state recording module, state update module and protocol execution module, such as Figure 1 As shown. All messages from other nodes in the system will first be sent to the state recording module, and then sent to the state update module and the protocol execution module according to the message situation. It should be noted that the three modules can be executed in parallel. The following is an introduction to the workflow of the three modules.

[0041] (1) Status Recording Module

[0042] like Figure 2 As shown, the state recording module maintains an internal state set {H, ht}, where the set H = {h1, h2, ..., h n}, h i Record the maximum height value contained in the message sent by the i-th node; ht is the nf-th highest value in H (reference height value), f is the number of faulty nodes that the asynchronous blockchain system can tolerate, and the ht value is used to guide the faulty node to recover to the "close to the latest" state, ensuring that even if there are up to f nodes that fail, the system can still obtain a reliable height threshold for synchronization. When the nf-th highest element in H is greater than 0, the value is sent to the state update module. When the value of the nf-th highest element changes, the changed value is sent to the state update module. After other node messages enter the state recording module, they are first classified as follows:

[0043] 1) If the message is sent to the status update module, it is directly forwarded to the status update module;

[0044] 2) If the message is not sent to the state update module, the message is forwarded to the protocol execution module. At the same time, the state recording module will also detect whether the message contains a height value. If not, it will be directly forwarded to the protocol execution module; if it contains a height value h and the message comes from the kth node, the state recording module compares h with the local height h k The size of k If h is large, k The value of is updated to h; and check whether the ht value needs to be updated. If it needs to be updated, the updated ht value is sent to the status update module and the protocol execution module.

[0045] (2) Status Update Module

[0046] like Figure 3 As shown, the state update module maintains an internal state set {h old ,h new ,T,S}, where h old is the height value of the faulty node before the fault, h new is the maximum ht value sent by the status recording module, T = {t|h old <t≤h new} is h old and h new The set of height values ​​t between them, S = {s1,s2,…,s k} is a set of state values ​​s corresponding to the height values ​​in set T obtained from other nodes. The state value is the blockchain state at a certain height. The state update module will ask other nodes for the state value corresponding to the height of the blockchain in set T. After the node is synchronized to the latest state and successfully participates in the execution of the blockchain protocol, the state update module will continue to run to help other possible faulty nodes. This state update module receives three types of messages:

[0047] 1) The protocol execution module sends h old , the state update module changes the internal state h old Set to this value;

[0048] 2) The ht value sent by the status recording module, if ht is greater than the local value h new , h new Update to ht value;

[0049] 3) The message sent by the state recording module is the state value st corresponding to a certain height value h sent by other nodes (for example, the jth node). The state update module checks the local state. If h = t i ∈T, and s i If the state value from the jth node is not recorded in s, the state value st is recorded in s i If s i If there are exactly f+1 identical state values ​​st, then (t i ,st) is sent to the protocol execution module.

[0050] (3) Protocol execution module

[0051] like Figure 4 As shown, the protocol execution module maintains an internal state set {h old ,ht,ST}, where h old Record the height value of the faulty node before the fault, ht records the highest ht value received, and ST is the set of all states related to the blockchain. This protocol execution module receives three types of messages:

[0052] 1) Sent by the status update module (t i ,st), the protocol execution module updates the internal state ST and the corresponding height value t i The state value of is set to st. If the state values ​​before ht have been obtained, the blockchain protocol execution submodule is activated to try to participate in the blockchain protocol execution;

[0053] 2) The ht value sent by the status recording module, the protocol execution module updates the local status height value ht to the maximum ht value;

[0054] 3) For the message sent by the state recording module, the protocol execution module first determines whether the message is a message requesting a state value of a certain height value. If not, the message is cached. If so, the local state ST is accessed to see if it has the corresponding height value h. i The status value s i , if yes, then (h i ,s i ) to the requester.

[0055] It should be understood that the "system" and "device" used in this specification are a method for distinguishing different components, elements, parts, parts or assemblies at different levels. However, if other words can achieve the same purpose, the words can be replaced by other expressions.

[0056] As shown in this specification and claims, unless the context clearly indicates an exception, the words "a", "an", "an" and / or "the" do not refer to the singular and may also include the plural. Generally speaking, the terms "comprise" and "include" only indicate the inclusion of the steps and elements that have been clearly identified, and these steps and elements do not constitute an exclusive list. The method or device may also include other steps or elements.

[0057] Flowcharts are used in this specification to illustrate the operations performed by the system according to the embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed precisely in order. Instead, the steps may be processed in reverse order or simultaneously. At the same time, other operations may also be added to these processes, or one or more operations may be removed from these processes.

[0058] The basic concepts have been described above. Obviously, for those skilled in the art, the above detailed disclosure is only for example and does not constitute a limitation of this specification. Although not explicitly stated here, those skilled in the art may make various modifications, improvements and corrections to this specification. Such modifications, improvements and corrections are suggested in this specification, so such modifications, improvements and corrections still belong to the spirit and scope of the exemplary embodiments of this specification.

[0059] At the same time, this specification uses specific words to describe the embodiments of this specification. For example, "one embodiment", "an embodiment", and / or "some embodiments" refer to a certain feature, structure or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that "one embodiment" or "an embodiment" or "an alternative embodiment" mentioned twice or more in different positions in this specification does not necessarily refer to the same embodiment. In addition, certain features, structures or characteristics in one or more embodiments of this specification can be appropriately combined.

[0060] In addition, it will be understood by those skilled in the art that various aspects of this specification may be illustrated and described by a number of patentable categories or situations, including any new and useful process, machine, product or combination of substances, or any new and useful improvements thereto. Accordingly, various aspects of this specification may be performed entirely by hardware, entirely by software (including firmware, resident software, microcode, etc.), or by a combination of hardware and software. The above hardware or software may be referred to as "data blocks", "modules", "engines", "units", "components" or "systems". In addition, various aspects of this specification may be represented as a computer product located in one or more computer-readable media, which includes computer-readable program code.

[0061] A computer storage medium may include a propagated data signal containing computer program code, for example, in baseband or as part of a carrier wave. The propagated signal may be in a variety of forms, including electromagnetic, optical, etc., or a suitable combination. A computer storage medium may be any computer-readable medium other than a computer-readable storage medium, which can be connected to an instruction execution system, device or apparatus to communicate, propagate or transmit the program for use. The program code on the computer storage medium may be transmitted via any suitable medium, including radio, cable, fiber optic cable, RF, or similar media, or any combination of the above media.

[0062] The computer program code required for the operation of each part of this specification can be written in any one or more programming languages, including object-oriented programming languages ​​such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB.NET, Python, etc., conventional procedural programming languages ​​such as C language, Visual Basic, Fortran2003, Perl, COBOL2002, PHP, ABAP, dynamic programming languages ​​such as Python, Ruby and Groovy, or other programming languages, etc. The program code can be run entirely on the user's computer, or run on the user's computer as an independent software package, or run partially on the user's computer and partially on a remote computer, or run entirely on a remote computer or processing device. In the latter case, the remote computer can be connected to the user's computer through any network form, such as a local area network (LAN) or a wide area network (WAN), or connected to an external computer (e.g., via the Internet), or in a cloud computing environment, or used as a service such as software as a service (SaaS).

[0063] In addition, unless explicitly stated in the claims, the order of the processing elements and sequences described in this specification, the use of alphanumeric characters, or the use of other names are not intended to limit the order of the processes and methods of this specification. Although the above disclosure discusses some invention embodiments that are currently considered useful through various examples, it should be understood that such details are only for illustrative purposes, and the attached claims are not limited to the disclosed embodiments. On the contrary, the claims are intended to cover all modifications and equivalent combinations that are consistent with the essence and scope of the embodiments of this specification. For example, although the system components described above can be implemented by hardware devices, they can also be implemented only by software solutions, such as installing the described system on an existing processing device or mobile device.

[0064] Similarly, it should be noted that in order to simplify the description disclosed in this specification and thus help understand one or more embodiments of the invention, in the above description of the embodiments of this specification, multiple features are sometimes combined into one embodiment, figure or description thereof. However, this disclosure method does not mean that the features required by the subject matter of this specification are more than the features mentioned in the claims. In fact, the features of the embodiments are less than all the features of the single embodiment disclosed above.

[0065] In some embodiments, numbers describing the number of components and attributes are used. It should be understood that such numbers used in the description of the embodiments are modified by the modifiers "about", "approximately" or "substantially" in some examples. Unless otherwise specified, "about", "approximately" or "substantially" indicate that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may change according to the required features of individual embodiments. In some embodiments, the numerical parameters should take into account the specified significant digits and adopt the general method of retaining digits. Although the numerical domains and parameters used to confirm the breadth of their range in some embodiments of this specification are approximate values, in specific embodiments, the setting of such numerical values ​​is as accurate as possible within the feasible range.

[0066] Each patent, patent application, patent application publication, and other materials, such as articles, books, specifications, publications, documents, etc., cited in this specification are hereby incorporated by reference in their entirety. Except for application history documents that are inconsistent with or conflicting with the contents of this specification, documents that limit the broadest scope of the claims of this specification (currently or later attached to this specification) are also excluded. It should be noted that if the descriptions, definitions, and / or use of terms in the materials attached to this specification are inconsistent or conflicting with the contents described in this specification, the descriptions, definitions, and / or use of terms in this specification shall prevail.

[0067] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0068] Finally, it should be understood that the above embodiments are only used to illustrate the principles of the present invention and to clearly and completely describe the technical solutions of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. The above embodiments are provided as examples rather than limitations, and alternative configurations of the embodiments of the present invention may be considered to be consistent with the teachings of the above embodiments. The technical solutions of the present invention are not limited to the implementation of the above embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

Claims

1. A method for recovering a failed node in an asynchronous blockchain system, characterized in that: The following steps are involved: 1) Receive messages from other nodes in the asynchronous blockchain system except the currently failed node; 2) If the target of the message is not a status update, then update the locally stored height value according to the node identity and height value contained in the message; and determine whether the message requires a status value of a certain height value. If so, check whether there is a status value of the corresponding height value locally and return it; 3) Get the updated height value h new and the height value h of the current faulty node before the fault old , and get h from all other nodes old and h new The status value of the height value between is recorded locally; 4) If the target of the message is a state update, the local state is updated according to the relationship between the height value and the corresponding state value contained in the message and the height value and the corresponding state value stored locally, the state value related to the blockchain is updated according to the number of locally updated state values, and the blockchain protocol is executed.

2. The method according to claim 1, characterized in that The height value stored locally in step 2) includes a height set H and a reference height value ht, where H contains n-1 elements, corresponding to the maximum height value contained in the message sent by each other node; n is the number of nodes in the system; ht is the nfth largest height value in the set H, and f is the number of faulty nodes tolerated by the asynchronous blockchain system.

3. The method according to claim 1, characterized in that The step of updating the locally stored height value according to the node identity and height value contained in the message in step 2) includes: for the node identity contained in the message, comparing the height value contained in the message with the height value of the node stored locally; if the height value contained in the message is greater than the height value of the node stored locally, updating the locally stored height value of the node to the height value contained in the message.

4. The method according to claim 1, characterized in that When updating the locally stored height value in step 2), check whether the ht value needs to be updated; if the ht value is greater than the local maximum height value h new , then h new Update to ht value and use it as the updated height value h in step 3) new .

5. The method according to claim 1, characterized in that The step of updating the local state according to the relationship between the height value and the corresponding state value contained in the message and the height value and the corresponding state value stored locally in step 4) comprises: for the node identity contained in the message, determining whether the height value contained in the message is within h old and h new If, and the status value corresponding to the height value contained in the message has not been stored locally, the status value corresponding to the height value contained in the message is updated locally.

6. The method according to claim 1, characterized in that In step 4), the method for updating the state value related to the blockchain according to the number of locally updated state values ​​is as follows: if the local receives f+1 identical state values ​​about the same height value from different nodes, then the state value related to the blockchain is updated, where f is the number of faulty nodes tolerated by the asynchronous blockchain system.

7. A recovery system for failed nodes in an asynchronous blockchain system, characterized in that: include: The state recording module is used to receive messages from other nodes in the asynchronous blockchain system except the current faulty node, and determine whether the message is sent to the state update module. If so, it is directly forwarded, otherwise the message is forwarded to the protocol execution module, and the local height value is updated according to the node identity and height value contained in the message. The local height value includes the height set H and the reference height value ht; check whether the ht value needs to be updated. If it needs to be updated, the updated ht value is sent to the state update module and the protocol execution module; The status update module is used to obtain the ht value from the status recording module and update the height value h new , obtain the height value h of the faulty node before the fault through the protocol execution module old and obtain from all other nodes the values ​​between h old and h new The state value corresponding to the height value between is stored locally; a message whose target is state update is obtained from the state recording module, and the local state is updated according to the relationship between the height value and the corresponding state value contained in the message and the local height value and the corresponding state value, and the update result is sent to the protocol execution module; The protocol execution module is used to update the local maximum height value according to the ht value sent by the status recording module; determine whether the message sent by the status recording module requests a status value of a certain height value, and if so, check whether the local status value has a corresponding height value and return it; update the status value related to the blockchain according to the update result sent by the status update module, and execute the blockchain protocol.

8. The system according to claim 7, characterized in that The state recording module maintains an internal state set {H, ht}, where H contains n-1 elements, corresponding to the maximum height value contained in the message sent by each other node; ht is the nf-th highest value in the set H, and f is the number of faulty nodes tolerated by the asynchronous blockchain system.

9. The system according to claim 7, characterized in that The state update module maintains an internal state set {h old ,h new ,T,S}, where h old is the height value of the current faulty node before the fault, h new is the maximum ht value sent by the status recording module, T is h old and h new is the set of height values ​​between them, and S is the set of state values ​​corresponding to the height values ​​in set T obtained from other nodes.

10. The system according to claim 7, characterized in that The protocol execution module maintains an internal state set {h old ,ht,ST}, where h old is the height value of the current faulty node before the fault, ht is the nf-th highest value in the set H, f is the number of faulty nodes tolerated by the asynchronous blockchain system, and ST is the set of all blockchain-related states.

Images