A lightweight asynchronous byzantine fault tolerance consensus method

Abstract

The application discloses a lightweight asynchronous Byzantine fault-tolerant consensus method, which comprises a message distribution stage, a time slot synchronization stage and an asynchronous negotiation stage. In the message distribution stage, a sender node broadcasts a message of a running instance to other nodes, and sequentially delivers the message broadcasted by each node; in the time slot synchronization stage, the sender node broadcasts the latest progress of the current broadcast to other nodes; in the asynchronous negotiation stage, the sender node votes on the delivered message, and sequentially outputs a message set. By using the application, all nodes can safely and efficiently ensure the same view. The application can be widely applied in the field of blockchains.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of blockchain, in particular to a lightweight asynchronous Byzantine fault tolerance consensus method. BACKGROUND

[0002] The success and wide application of blockchain and distributed scheduling technology in recent years have promoted the development of Byzantine fault tolerance consensus protocol. Byzantine fault tolerance consensus protocol can maintain a growing linear log, and even in the presence of malicious nodes, it can guarantee that honest nodes have the same view. Based on time assumption, Byzantine fault tolerance consensus protocol can be divided into synchronous, partially synchronous and asynchronous. Synchronous or partially synchronous protocol relies on time assumption and needs to manually design a message transmission delay upper bound. This not only cannot meet the specific network of real world dynamic confrontation, but also increases the difficulty of implementing blockchain or distributed scheduling system. In particular, when there is an enemy that can arbitrarily delay messages, synchronous or partially synchronous Byzantine consensus protocol may not make any progress.

[0003] Asynchronous Byzantine fault tolerance consensus protocol, which does not rely on any time assumption, is considered to be the most suitable consensus protocol for deployment in the real world. Generally speaking, asynchronous Byzantine fault tolerance protocol consists of a message distribution phase and an asynchronous negotiation phase. In the message distribution phase, each node sends its input message to all nodes by broadcasting instances. In the asynchronous negotiation phase, the correct stage agrees on the output message.

[0004] However, existing asynchronous Byzantine fault tolerance consensus protocols have suboptimal structures, such as the asynchronous negotiation phase always blocking subsequent message distribution nodes, resulting in poor protocol performance. Although some work attempts to solve this problem by running the message distribution and asynchronous negotiation phases concurrently, it relies on complex cryptographic primitives such as threshold signatures, which makes the protocol have security and performance problems, such as being vulnerable to quantum attacks by the enemy and a dramatic increase in computing cost. SUMMARY

[0005] Therefore, in order to solve the technical problem that the existing asynchronous Byzantine fault tolerance consensus method is vulnerable to quantum attacks, the present application proposes a lightweight asynchronous Byzantine fault tolerance consensus method that decouples the asynchronous Byzantine fault tolerance protocol without using any signature, which comprises the following steps:

[0006] Initialize a blockchain system consisting of n nodes, assign a unique identity to each node, and establish a two-way channel between all nodes.

[0007] The consensus method consists of three stages: message distribution, time slot synchronization and asynchronous negotiation.

[0008] In each time slot of the message distribution phase, the sender node randomly selects a batch of transactions from its buffer.

[0009] Each sender node encodes the transaction and sends the time slot and corresponding encoded block message to the corresponding nodes via the broadcast protocol.

[0010] Upon receiving a message from a sender node, a node first verifies the message for validity, and if valid, sends it to other nodes.

[0011] Upon receiving n-f valid time slot values and encoded block messages from other nodes, a node sends a READY message to all nodes indicating that it has received a sufficient number of valid encoded blocks.

[0012] Upon receiving f+1 READY messages from other nodes, a node sends a message to all nodes if it has not already sent the message.

[0013] Upon receiving 2f+1 READY messages and valid encoded blocks, a node decodes all encoded blocks, delivers the message, and enters the next time slot.

[0014] Upon delivering a new transaction message from n-f nodes, a node enters the next time slot and repeats the above operations.

[0015] In the time slot synchronization phase, each sender node broadcasts its latest progress in the message distribution phase to all nodes.

[0016] Upon receiving the latest progress from a sender node, a node broadcasts the progress to all other nodes.

[0017] If a node receives the same new progress from n-f nodes, it broadcasts a confirmation message to all nodes.

[0018] If a node receives confirmation messages from f+1 nodes and has not sent the message, it broadcasts the confirmation message to all nodes.

[0019] If a node receives confirmation messages from 2f+1 nodes, it enters the asynchronous agreement phase.

[0020] In the asynchronous agreement phase, if a node delivers a message corresponding to the latest progress of a node, it inputs 1 to the asynchronous binary consensus instance corresponding to the node, i.e., broadcasts a BVAL message with value 1.

[0021] If a node has input 1 to n-f asynchronous binary consensus instances, it inputs 0 to the remaining instances, i.e., broadcasts a BVAL message with value 0.

[0022] If a node broadcasts a BVAL message with value 1, it directly broadcasts an AUX message with value 1.

[0023] If the node receives f+1 BVAL messages from other nodes, it will perform the following operations:

[0024] If the node has not sent the value carried by the BVAL message, it will send the message to all nodes;

[0025] If the value carried by the BVAL message is 1, the node will directly send an AUX message with the value 1.

[0026] When the node receives BVAL messages from n-f nodes, and it has not sent any AUX message, the node will send an AUX message to all nodes.

[0027] When the node receives AUX messages from n-f nodes, it will perform the following operations:

[0028] If the n-f AUX messages carry the same value b, the node will enter the next round with b; further, if b is equal to the value of the tossed coin, the node will output b;

[0029] In other cases, the node will enter the next round with the value of the tossed coin.

[0030] After the termination of the asynchronous negotiation phase, the node updates the time slot value that has been agreed upon, and outputs all messages in a certain order.

[0031] Based on the above scheme, the application provides a lightweight asynchronous Byzantine fault-tolerant consensus method, which decouples the message distribution phase and the asynchronous negotiation phase under a non-signature setting, and reaches an agreement on the latest progress of the current broadcast message by introducing a time slot synchronization phase, thereby constructing a lightweight asynchronous Byzantine fault-tolerant consensus protocol, so as to ensure that the protocol can simultaneously consider strong security (for example, quantum security) and high performance. Under this favorable condition, the method of the application can be further deployed to a blockchain system or a distributed scheduling system to ensure that each node can safely and efficiently realize a consistent view, avoid system crashes or task execution failures due to the failure of a certain node, and efficiently coordinate each node for task allocation and resource scheduling, thereby improving the reliability, efficiency and flexibility of the distributed scheduling system, and enabling the distributed scheduling system to better adapt to complex and variable task requirements. BRIEF DESCRIPTION OF DRAWINGS

[0032] Figure 1 is a step flowchart of a lightweight asynchronous Byzantine fault-tolerant consensus method of the application;

[0033] Figure 2 is a detailed flowchart of a lightweight asynchronous Byzantine fault-tolerant consensus method of the application. DETAILED DESCRIPTION

[0034] The state-of-the-art design of existing signatureless asynchronous Byzantine fault-tolerant consensus protocols is still hindered by the inherent mutual waiting between the broadcast and agreement phases. Specifically, in each round, the consensus protocol values the message dissemination phase before the asynchronous agreement phase. Therefore, the message dissemination nodes of each round have to wait for the completion of the asynchronous agreement phase of the previous round. In addition, a frequently overlooked but crucial constraint is that the asynchronous agreement phase for a new round also has to wait for the completion of the message dissemination phase of the current round. Although some works attempt to address the above issues, they heavily rely on threshold signatures, which makes the protocols suffer from security and performance problems, such as being vulnerable to quantum attacks by an adversary and a dramatic increase in computational cost. In particular, due to the different underlying consensus protocol architectures, the existing methods cannot solve the above problems.

[0035] Asynchronous Byzantine binary agreement (ABA): In ABA, each node inputs a binary value and agrees on the input value. At the end of the ABA protocol, the following properties are satisfied:

[0036] 1. Validity: If all correct nodes input, then all correct nodes eventually output;

[0037] 2. Agreement: If a correct node outputs, then all correct nodes output;

[0038] 3. Termination: Each correct node eventually outputs some value;

[0039] 4. Integrity: Each correct node outputs at most one value.

[0040] The main challenge faced by the existing solution is that all correct nodes must agree on each broadcasted valid progress, which indicates that the broadcast has indeed progressed here. To solve this problem, the existing solution introduces a certificate obtained from 2f+1 (partial) signatures, so that an adversary cannot forge a certificate for some unfinished broadcast progress. The challenge faced by the decoupling of the message dissemination and asynchronous agreement phases in the present method is that correct nodes may reach consensus on different messages in the asynchronous agreement phase, which will cause the protocol to violate the security properties.

[0041] The technical solutions in the embodiments of the present application will be described clearly and completely in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0042] It should be noted that only parts related to the present application are shown in the drawings for the convenience of description. The embodiments in the present application and the features in the embodiments can be combined with each other in the case of no conflict.

[0043] It should be understood that the terms “system”, “apparatus”, “unit” and / or “module” used in the present application are a method for distinguishing different components, elements, parts, sections or assemblies of different levels. However, if other words can achieve the same purpose, the words can be replaced by other expressions.

[0044] As shown in the present application and claims, unless the context clearly indicates otherwise, the words “one”, “a”, “an” and / or “the” do not mean to specify a single number, but can also include a plurality. Generally, the terms “comprise” and “include” only indicate that the steps and elements explicitly identified are included, and these steps and elements do not constitute an exclusive list, and the method or device can also include other steps or elements. The element defined by the phrase “comprising a” does not exclude the presence of additional identical elements in the process, method, product or device comprising the element.

[0045] In the description of the embodiments of the present application, “a plurality of” means two or more than two. The following terms “first”, “second” are only for the purpose of description, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined with “first”, “second” can explicitly or implicitly include one or more of the features.

[0046] In addition, flowcharts are used in the present application to illustrate the operations performed by the system according to the embodiments of the present application. It should be understood that the preceding or subsequent operations are not necessarily performed in sequence. On the contrary, each step can be processed in reverse order or simultaneously. Meanwhile, other operations can be added to these processes, or one or more steps of operations can be removed from these processes.

[0047] Reference Figure 1 The flowchart of an optional example of the lightweight asynchronous Byzantine fault-tolerant consensus method proposed in the present application can be applied to a computer device. The consensus method proposed in the present embodiment can include but is not limited to the following steps:

[0048] Step S1, a broadcast system is constructed, the broadcast system has consistency, totality, validity and time slot order;

[0049] Step S2, in the message distribution stage, the sender node broadcasts the message of the running instance to other nodes, and sequentially delivers the message broadcasted by each node;

[0050] Step S3, in the time slot synchronization phase, the sender node broadcasts its current broadcast progress to other nodes;

[0051] Step S4, in the asynchronous negotiation phase, the sender node votes on the messages it delivers, and outputs the message set in order.

[0052] In some possible embodiments, the step S1 specifically includes:

[0053] The broadcast ensures that all nodes can deliver messages in order in consecutive time slots;

[0054] The method of the present application introduces a new reliable broadcast primitive, which can ensure that all correct nodes deliver all messages in order in consecutive time slots. Overall, first, an explicit link is established between the message m to be broadcast and the time slot s, ensuring that all correct copies receive the same message in the same time slot. Then, if time slot s>s', all correct nodes should have delivered message m' of time slot s' before forwarding or delivering message m of time slot s. To ensure the smooth implementation of the above idea, the method of the present application first redefines the properties of reliable broadcast and introduces a new property. The various property definitions are as follows:

[0055] Consistency: if a correct node delivers message m in time slot s, and another correct node delivers message m' in time slot s, then m=m'.

[0056] Universality: if a correct node delivers message m in time slot s, then all correct nodes will eventually deliver message m in time slot s.

[0057] Effectiveness: if a correct sender node broadcasts message m in time slot s, then all correct nodes will eventually deliver message m in time slot s.

[0058] Time slot order: for any time slot s<s', there is no correct node that forwards or delivers any message of time slot s' before delivering message m of time slot s.

[0059] In some possible embodiments, the step S2 specifically includes:

[0060] A correct node p i First, randomly select a batch of messages m from its buffer i . Then, use (f+1, n)-erasure code to encode m i locally into n parts, where v j is the jth encoded block, h is the root hash of the Merkle tree, and b j is the Merkle proof of the jth encoded block.

[0061] Correct node pi to each node p j send a VAL(s i ,h,v j ,b j ) message, where s i is the current latest slot value of node p i , and j e [n]. When node p i receives a message VAL(s j ,h,v j ,b i ) from node p i , it will wait until s j = 1 or the message corresponding to slot s j - 1 has been delivered by p i . Then, p i performs the following operations:

[0062] If p_i has not broadcasted an ECHO message for slot s j , p i broadcasts ECHO(s j ,h,v i ,b i ) and adds s j to echo[j]; if s j e delivered[j], i.e., p i has delivered a message for slot s j , it will terminate the progress of the current slot.

[0063] When node p i receives an ECHO(s j ,h,v k ,b j ) message from node p j , it will wait until s k = 1 or the message corresponding to slot s k - 1 has been delivered by p i . Then, p i performs the following operations:

[0064] p i checks whether v j and h are valid by a Merkle proof b j , and discards if not.

[0065] When node p i receives ECHO(s j ,h,*,*) messages from n-f different nodes, it will wait until s j = 1 or the message corresponding to slot s j-1 corresponding message has been delivered by p i . Then, p i performs the following operations:

[0066] Interpolates the received any n-2f v j ; calculates the Merkle root hash h' and compares h' with h, if not equal, terminates the protocol; if h'=h, and p i has not sent a READY message, it will send a READY(s j , h) message to all nodes.

[0067] When node p i receives READY(s j , h) messages from f+1 different nodes, it will wait s j =1 or the time slot s j -1 corresponding message has been delivered by p i . Then, p i performs the following operations:

[0068] If p i has not sent a READY message, it will broadcast a READY(s j , h).

[0069] When node p i receives READY(s j , h) messages from 2f+1 different nodes, it will wait s j =1 or the time slot s j -1 corresponding message has been delivered by p i , and received n-2f valid ECHO messages. Then, p i performs the following operations:

[0070] p i decodes all encoding blocks using interpolation method to obtain the message m j ; p i delivers the message m j of time slot s j and adds s j to the set delivered[j].

[0071] In some possible embodiments, the step S3 specifically comprises:

[0072] The method of the present application introduces a new phase in the asynchronous Byzantine fault-tolerant consensus protocol, called time slot synchronization phase, which aims to ensure that all correct replicas have the same time slot value.

[0073] Each correct node pi broadcasts a message to all nodes, where is p i the current largest slot value, and i denotes that the message comes from p i . When node p i receives a message from another node p j , it broadcasts a message to all nodes. When node p i receives a message from n-f different nodes, it broadcasts a message to all nodes. When node p i receives a message from f+1 different nodes, it performs the following operations:

[0074] If p i has not sent any Final-Sync message, it broadcasts a message to all nodes.

[0075] When node p i receives a message from 2f+1 different nodes, it outputs

[0076] In some possible embodiments, the step S4 specifically comprises:

[0077] In the asynchronous agreement phase, all correct nodes agree on the set to output.

[0078] The asynchronous agreement protocol is executed in rounds, starting from round 0. In round 0, each correct replica p i inputs a binary value b and sets est0 = b. If est0 = 0 and p i subsequently completes a broadcast instance, he rebroadcasts BVAL0(1). p i broadcasts BVAL0(est0) to all nodes and performs the following operations:

[0079] If est0 = 1, p i adds est0 to the bin_values0 set. If p i has not sent any AUX message, it sends AUX0(1) to all nodes.

[0080] When node p i receives a BVAL0(b) message from f+1 different nodes, it performs the following operations:

[0081] If p i has not sent any BVAL0(b) messages, it will send a BVAL0(b) message to all nodes; if b = 1 and p i has not sent any AUX messages, p i will send an AUX0(1) message to all nodes.

[0082] When node p i receives a BVAL0(b) message from 2f+1 different nodes, it will perform the following operations:

[0083] If p i has not added b to its bin_values0 set, p i adds b to bin_values0; if p i has not sent any AUX messages, it will send an AUX0(b) message to all nodes.

[0084] When node p i receives an AUX0(*) message from n-f different nodes, it adds the value carried by the AUX0() message to vals0 and sets the common coin value for round 0 to 1, and then performs the following operations:

[0085] If vals0 = b, p i sets est1 = b; further, if b = 1, p i outputs b; otherwise, p i sets est1 = 1.

[0086] In round r > 0, p i sends a BVAL r (est r ) message to all nodes. When node p i receives a BVAL r (b) message from f+1 different nodes, if it has not sent a BVAL r (b), p i sends a BVAL r (b) message to all nodes. When node p i receives a BVAL r (b) message from 2f+1 different nodes, it will perform the following operations:

[0087] If p i has not added b to its bin_values r set, it adds b to bin_values r ; if p i has not sent any AUX messages, pi Send AUX to all nodes r (b) messages.

[0088] When node p i receives AUX r (*) messages from n-f different nodes, it adds the values carried by AUX r to the set vals r (p i will only add different values), and sends CONF r (vals r ) to all nodes. When node p i receives CONF r (S) messages from n-f different nodes, it adds the values in S to the set S r and invokes the coin-flipping protocol to obtain a random value s r and then performs the following operations:

[0089] If S r = b, p i sets est r+1 = b; if b = s r , p i outputs b. Otherwise, p i sets est r+1 = s r . Then, p i enters the next round.

[0090] In some possible embodiments, further comprising:

[0091] In an asynchronous Byzantine fault-tolerant consensus protocol, a correct node p i will invoke the phases according to the following rules.

[0092] First, a correct node p i initializes the slot s i to 1. Node p i maintains a growing broadcast instance. Specifically, p i randomly selects a message m i from its buffer, and inputs the slot s i and the message m i to its broadcast instance. When p i completes its broadcast instance, it enters the next slot.

[0093] Upon initialization, a correct node p i first initializes the ordered list [ordered1,..., ordered n] is [0,...,0] and the period e is 1. In each period e, node p i First, initialize [slot1,...,slot n ] to [0,...,0]. When node p i receives a message (slot j ,m j ) from node p j , and s j >ordered j , p i will perform the following operations:

[0094] If period e>1 and j=i, p i calls the function Slot_Sync of the time slot phase with (s j ,j) as input and waits for the return slot j . Otherwise, p i sets slot j =s j .

[0095] When node p i receives a message (slot j ,m j ) from node p j , if the asynchronous negotiation phase of p j has not started yet, p i inputs 1 to the negotiation instance of p j . Otherwise, p i re- inputs 1 to the negotiation instance of p j . When p i inputs binary values to n-f negotiation instances, it inputs 0 to all negotiation instances that have not started yet. When p i completes all negotiation instances, it waits for all broadcast messages to be delivered, outputs these messages, and updates [ordered1,...,ordered n ].

[0096] The specific process of combining steps S1, S2 and S3 is described with reference to Figure 2 .

[0097] A lightweight asynchronous Byzantine fault-tolerant consensus device:

[0098] At least one processor;

[0099] At least one memory for storing at least one program;

[0100] When the at least one program is executed by the at least one processor, the at least one processor implements a lightweight asynchronous Byzantine fault-tolerant consensus method as described above.

[0101] The contents in the method embodiments are applicable to the device embodiments, the device embodiments specifically implement the functions same as the method embodiments, and achieve the beneficial effects same as the method embodiments.

[0102] A storage medium, wherein the storage medium stores processor-executable instructions that, when executed by a processor, are configured to implement a lightweight asynchronous Byzantine fault tolerance consensus method.

[0103] The contents in the method embodiments are applicable to the storage medium embodiments, the storage medium embodiments specifically implement the functions same as the method embodiments, and achieve the beneficial effects same as the method embodiments.

[0104] The above is a specific description of the preferred embodiments of the application, but the application is not limited to the embodiments described, and those skilled in the art can make various equivalent modifications or replacements without departing from the spirit of the application. These equivalent modifications or replacements are all included in the scope defined by the claims of the present application.

Claims

1. A lightweight asynchronous Byzantine fault-tolerant consensus method, characterized in that, Includes the following steps: Construct a broadcast system that possesses consistency, comprehensiveness, effectiveness, and time-slot ordering; During the message distribution phase, the sender node broadcasts the message of the running instance to other nodes and transmits the message broadcast by each node in an orderly manner. During the time slot synchronization phase, the sender node broadcasts the latest progress of its current broadcast to other nodes; During the asynchronous negotiation phase, each sender node votes on the messages it transmits and outputs the message set in order; The message distribution phase specifically includes: The sender node selects a batch of transactions from its buffer and encodes them, then sends the time slot and the corresponding encoded block message to the corresponding node via a broadcast protocol; After receiving a message from the sender node, verify the validity of the message and send the verified message to other nodes; After a node receives nf valid slot values ​​and coded block messages from other nodes, it sends a first response message to all nodes. After a node receives f+1 first response messages from other nodes, if it has not yet sent the message, it sends it to all nodes. After receiving 2f+1 first response messages and valid encoded blocks, the node decodes all encoded blocks, transmits the message, and enters the next time slot; Where n is the total number of nodes and f is the number of malicious nodes; The step in which the sender node selects a batch of transactions from its buffer, encodes them, and then sends the time slot and the corresponding encoded block message to the corresponding node via a broadcast protocol specifically includes: node p i In each time slot s i After randomly selecting a batch of messages m, encode m into v locally using erasure coding with a formula of (n-2f,n). j ; In v j Construct a Merkle tree, calculate the Merkle root hash h, and send VAL(s) to each node. i ,h,b j ,v j ) message, of which b j It is v j The corresponding Merkel branch; The step of verifying the validity of a message after receiving it from the sender node and sending the verified message to other nodes specifically includes: node p i Received VAL(s) j ,h,b i ,v i After the message, calculate b. i and v i And obtain the Merkle root hash value h', and determine whether h is equal to h'; If h = h', p i Send ECHO(s) to all nodes j ,h,b i ,v i )information; node p i Receive ECHO(s) from other nodes k ,h,b j ,v j ) message, calculate b j and v j And obtain h', and determine whether h is equal to h'; node p i Received nf valid ECHO(s) j ,h,*,*) messages or f+1 READY(s) j The READY(s) message broadcasts to all nodes. j ,h) message; node p i Received 2f+1 READY(s) j The message (,h) waits for n-2f valid ECHO(s) messages. j ,h,*,*) message, decode v j And obtain m; The time slot synchronization stage also includes: When a node makes new progress, it sends the largest timeslot value corresponding to the broadcast it has currently completed to all nodes. Each node will receive this timeslot value and output the same timeslot value. The step whereby, when a node makes new progress, it sends the largest timeslot value corresponding to its currently completed broadcast to all nodes, and each node receives this timeslot value and outputs the same timeslot value, specifically includes: node p i Send to all nodes Messages, including It is p i The largest time slot value that has been completed, i is p i The subscript value; When node p i Received After the message is sent, it will send it to all nodes. information; When node p i Received nf Message or f+1 After the message is sent, it will send it to all nodes. information; When node p i Received nf After the message, output The step of each sender node voting on the messages it transmits and outputting the message set in order specifically includes: In time slot s i Node p i Use a randomly selected message m as input to the reliable broadcast instance; When node p i Output time slot s i After receiving the message, it enters the next time slot; When node p i New time slots were output. After receiving the message, it broadcasts it to all nodes. When node p i Received time slot Then it will send to p j Input 1 for the asynchronous negotiation instance; When node p i After providing input to nf negotiation instances, it will input 0 to the remaining instances; Waiting for all negotiation instances to terminate, node p i Output all messages in the preset order.

2. The lightweight asynchronous Byzantine fault-tolerant consensus method according to claim 1, characterized in that, The asynchronous negotiation phase also includes: If the current node transmits a time slot The corresponding message will prompt the node to input a preset value to the corresponding negotiation instance according to the preset rules, and reach a consensus on the output.

3. The lightweight asynchronous Byzantine fault-tolerant consensus method according to claim 2, characterized in that, If the current node transmits a time slot The corresponding message involves the node inputting preset values ​​to the corresponding negotiation instance according to preset rules, and reaching a consensus on the output. This process specifically includes: In each negotiation instance, node p i It will broadcast its input value to all nodes; After receiving messages broadcast by other nodes, node p i We will respond to these messages; When node p i Once enough messages are received, the coin toss protocol will be invoked, and then either the next round will begin or a binary value will be output.

4. A lightweight asynchronous Byzantine fault-tolerant consensus device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements a lightweight asynchronous Byzantine fault-tolerant consensus method as described in any one of claims 1-3.

Images