A method of implementing a total-order broadcast in a distributed system, corresponding computer program product, node and distributed system

Abstract

There is described a method of implementing a total-order broadcast in a distributed system (1) comprising a plurality of processes (12), the method comprising: - receiving a request signal (R) comprising a message (M) and a bet (B), wherein the bet (B) is indicative of a time instant, and - introducing the message (M) in an ordered set (2), the set (2) ordered as a function of increasing bet (B) and comprising a number of messages (M) to be delivered in a total order.

Description

[0001] A METHOD OF IMPLEMENTING A TOTAL-ORDER BROADCAST IN A DISTRIBUTED SYSTEM, CORRESPONDING COMPUTER PROGRAM PRODUCT , NODE AND DISTRIBUTED SYSTEM

[0002] Technical Field

[0003] The present invention relates to a method for distributed (Byzantine ) systems comprising a plurality of N processes and having a number of malicious or faulty processes f . In particular, the present invention relates to a method for of implementing a total-order or atomic broadcast in a distributed system and to corresponding computer program product , node and distributed system .

[0004] Background Art

[0005] Total-Order Broadcast or atomic broadcast is among the most studied abstractions in the field of distributed computing and is at the base of State Machine Replication and unlocking universal , transparent , reliable computing in the face of malicious or faulty nodes . Real-world implementation of this abstraction can power a great variety of f ault-tolerant applications , as exempli fied most prominently by blockchain-based financial systems .

[0006] In particular, Total-Order Broadcast or TOB has processes ( servers or nodes ) agree on a totally ordered sequence of client-issued messages . Conventionally, Total- Order Broadcast is often implemented using multiple instances of Byzantine Consensus which has processes ( or servers or nodes ) agree on a common decision .

[0007] The consensus allows to achieve a common sequence of messages by having servers or processes or nodes successively agree on which messages to deliver next , thereby generating a Total-Order Broadcast .

[0008] In brief , Total-Order Broadcast or TOB or atomic broadcast has correct processes or servers agree on a totally ordered sequence of client-issued messages . The interface to a Total-Order Broadcast instance can comprise two events : a request , which a correct client can use to broadcast a message ; and an indication, which a correct server uses to indicate the delivery of the message from the server . Total-Order Broadcast ensures :

[0009] - no duplication : no correct server delivers the same message from the same sender twice ;

[0010] - integrity : a correct server delivers a message from a correct client only i f the client broadcasts the message ;

[0011] - validity : every message broadcast by a correct client is eventually delivered by a correct server ; and

[0012] - agreement and Total Order : every correct server eventually delivers the same messages in the same order .

[0013] Di f ferent alternatives methods or algorithms are known to implement a Total-Order Broadcast , however such methods have one or more disadvantages , for example the methods are overly complex, slow, rely on a leader and / or signatures are needed. An introduction to Total-Order or atomic broadcast can be found in "Introduction to Reliable and Secure Distributed Programming", Christina Cachin, Rachid Guerraoui, Luis Rodrigues, Springer.

[0014] Byzantine agreement and Total-Order protocols employ one or multiple leaders and require multiple communication steps to safely terminate, see e.g. the following articles:

[0015] - Ittai Abraham, Kartik Nayak, Ling Ren, and Zhuolun Xiang. 2021. Good-case Latency of Byzantine Broadcast: a Complete Categorization. In Proceedings of the 2021 ACM Symposium on Principles of Distributed Computing (PODC) . https: / / doi.org / 10.1145 / 3465084.3467899,

[0016] Alysson Bessani, Joao Sousa, and Eduardo E.P. Alchieri. 2014. State Machine Replication for the Masses with BFT-SMaRt. In 2014 44th Annual IEEE / IFIP International Conference on Dependable Systems and Networks (DSN) . https: / / doi.org / 10.1109 / DSN.2014.43,

[0017] Zeta Avarikioti, Lioba Heimbach, Roland Schmid, Laurent Vanbever, Roger Wattenhofer, and Patrick Wintermeyer. 2023. FnF-BFT: A BET protocol with provable performance under attack. In 30th International Colloquium on Structural Information and Communication Complexity (SIROCCO) ,

[0018] - Chrysoula Stathakopoulou, Matej Pavlovic, and Marko

[0019] Vukolic. 2022. State Machine Replication Scalability Made Simple. In Proceedings of the Seventeenth European Conference on Computer Systems (EuroSys) . https : / / doi .org / 10.1145 / , 3492321.3519579.

[0020] In particular, a leader submits the messages it collects to Consensus, which successively selects which messages are delivered next; if a leader is suspected having crashed or misbehaved, a new leader is selected to replace it. Having a leader can be disadvantageous in terms of time, especially if the leader becomes malicious or faulty .

[0021] A need is felt for providing a leaderless system without the disadvantages here described.

[0022] Multiple protocols have been proposed to solve crash f ault-tolerant Consensus in one step and / or Total-Order Broadcast in two steps in the good case, see e.g. Roy Friedman, Achour Mostefaoui, and Michel Raynal . 2005. Simple and Efficient Oracle-Based Consensus Protocols for Asynchronous Byzantine Systems, IEEE Transactions on Dependable and Secure Computing (TDSC) 2, 1 (2005) , https: / / doi.org / 10.1109 / TDSC.2005.13. However, such protocol requires a resiliency of (5 / + 1) and the existence of oracles, which may be implemented using a random common coin abstraction which in practice requires cryptographic tools to construct.

[0023] Additional protocols have been proposed to solve Byzantine Consensus in two steps, and Byzantine Total- Order Broadcast in three steps, using a fast path in the good case, see e.g. Klaus Kursawe. 2002. Optimistic Byzantine agreement. In 21st IEEE Symposium on Reliable Distributed Systems (SRDS) , https: / / doi.org / 10.1109 / RELDIS.2002.1180196. The article proposes a Consensus algorithm assuming an even "stronger" good case whereby all processes have to be correct to benefit from the fast path. A single process failures results in all processes having to use the slow path.

[0024] The article Massimo Albarello, Jakub Sliwinski, Yann Vonlanthen, and RogerWattenhof er , 2023, Fast Internet Computer Consensus, arXiv: 2312.05869, is the first Byzantine Total-Order Broadcast with a two-step fast path in the good case when the leader broadcasts a value, hence three-step fast path when any process broadcasts a value. However, the system still relies on a leader with a number of disadvantages as best described in the following.

[0025] The article defines a parametrizable resiliency threshold of 3f +2p +1 where f is the maximum number of Byzantine faulty or malicious processes and p is freely set such that 0 < p < f. A value is rapidly delivered if (f + p) processes are correct and respond fast enough.

[0026] For example, Guy Golan Gueta, Ittai Abraham, Shelly Grossman, Dahlia Malkhi, Benny Rinkas, Michael Reiter, Dragos-Adrian Seredinschi, Orr Tamir, and Alin Tomescu, 2019, SBFT: A Scalable and Decentralized Trust Infrastructure, In 2019 49thAnnual IEEE / IFIP International Conference on Dependable Systems and Networks (DSN) , https: / / doi.org / 10.1109 / DSN, 2019.00063, needs four steps in the good case for Byzantine Total-Order Broadcast but could likely only need three steps by not using collectors to aggregate signatures, at the cost of higher computation complexity for processes hence lower Total-Order Broadcast throughput .

[0027] To the best of the Applicant's knowledge, all the protocols achieving two-step Byzantine Consensus and three-step Byzantine Total-Order Broadcast in fast paths employ leaders. The majority of these protocols further use signatures.

[0028] A need is thus felt for improving the known solutions. Summary of the invention

[0029] It is therefore an object of the present invention to provide a method of implementing a total-order broadcast in a Byzantine system that can overcome one or more of the aforementioned disadvantages.

[0030] It is an object of the present invention to provide a computer program product, able to perform the steps of the method of implementing a total-order broadcast. It is a further object of the present invention to provide a node and / or a distributed system comprising a plurality of processes and / or nodes .

[0031] In particular, the method comprises receiving a request signal comprising a message and a bet , wherein the bet is indicative of a time instant . The method may optionally comprise introducing the message in an ordered set , the set ordered as a function of increasing bet and comprising a number of messages to be delivered in a total order .

[0032] Advantageously, thanks to the instant method, the set can be ordered in an ef fective and cost-ef ficient manner, without the use of a leader . That is , thanks to the instant method, the system can be leaderless .

[0033] Accordingly, the present invention may provide one or more advantages :

[0034] - a leaderless nature , leader-based algorithms might sequentially force the protocol through ( f + 1 ) leaders before a message is delivered; this translates into a signi ficantly shorter worst-case latency, avoiding the adaptive-adversary scenario where a linear number of faulty leaders has to be detected and discarded before any progress is finally made ,

[0035] - no signatures , i . e . free of costly cryptographic primitives , improving CPU ef ficiency, weathering quantum attacks , and possibly enabling deployment on hardware- accelerated systems ,

[0036] - the method is deterministic,

[0037] - a good reliability is achieved insofar as the system remains correct even i f about 20% of the processes or nodes are malicious or faulty,

[0038] - limited number of steps in the method, i . e . an implementation without vulnerabilities is facilitated, also such methods are cheaper to implement and maintain, more amenable to formal veri fication, better compatible with hardware-accelerated systems and constrained hardware architectures ; furthermore simpler algorithms come with a reduced cybersecurity cross-section, inherently mitigating the danger that a single implementation vulnerability will nulli fy a system' s bid for f ault-tolerance and security,

[0039] - leaderless algorithms have also the potential for improved fairness ; unless dedicated logic is put in place to ensure fair ordering, leader-based implementations are usually vulnerable to a malicious leader af fecting the order of messages , e . g . , by censoring or front-running correct clients ,

[0040] - the algorithm is extremely fast in the good case : the method achieves an unprecedented latency of ( 2A + e) , where A bounds the message delay between any two processes , and e is an arbitrarily small interval of time ( e . g . , the shortest interval of time that a process can represent ) . Brief description of the drawings

[0041] Embodiments of the present invention will be described by way of example with reference to the accompanying drawings , in which :

[0042] - figure 1 is a schematic view of a distributed system according to one or more embodiments ,

[0043] - figure 2 depicts an example of signals exchanged on a distributed network over time t ,

[0044] - figure 3 exempli fies a possible order in the ordered set according to one or more embodiments ,

[0045] - figure 4 shows a flow chart of a method according to one or more embodiments , and

[0046] - figure 5 shows a flow chart of a method according to one or more embodiments , in a good case scenario .

[0047] Description of the invention

[0048] Figure 1 illustrates an example of a ( distributed) system 1 according to one or more embodiments . The system 1 can be a Byzantine system . The system 1 comprises a plurality of nodes 10 .

[0049] In the context of the present invention, a "node" refers to a computational entity within the (Byzantine distributed) system that hosts one or more processes 12 . Nodes 10 serve as the building blocks of the distributed system 1 , facilitating communication, computation, and coordination among processes 12 . Each node 10 typically has its own computational resources such as processing power, memory, and storage, and is capable of executing tasks and participating in the operation of the distributed system. Nodes 10 can comprise physical devices such as computers, servers, routers.

[0050] Accordingly, the node 10 can implement one or more processes 12. Also, the node 10 is connectable to a distributed network and / or is capable of generating, receiving, and / or transmitting data or signals over the system 1.

[0051] The system 1 can comprise a plurality of processes 12. As mentioned, the nodes 10 can implement the processes 12. In particular, a total number N of processes 12 may be at least N = 5f +1, where f represents a number of faulty or malicious processes 12.

[0052] In the context of the present invention, a "process" refers to an autonomous computational entity within the (Byzantine distributed) system. Each process 12 is capable of performing computations, communicating with other processes 12, and participating in the consensus or decision-making process of the system 1.

[0053] Any two processes 12 communicate via reliable, authenticated, FIFO (First In First Out) links, i.e., messages are delivered in the order they are sent.

[0054] The faulty or malicious processes 12 (i.e. Byzantine processes) may arbitrarily deviate from the algorithm they are assigned, falling under the complete control of a malicious adversary. Byzantine processes know each other and may collude and coordinate their actions. Also, Byzantine adversaries are adaptive, meaning that, subject to the Byzantine threshold constraint, such adversaries can choose which processes to compromise based on system and protocol state.

[0055] The system 1 may comprise processes 12, e.g. implemented in the nodes 10, configured to perform the steps of a method for implementing a total-order or atomic broadcast .

[0056] In addition, the system 1 may be connectable to client processes 12' , e.g. implemented in a client node 10' , configured for:

[0057] - calculating a bet B as a sum between a (e.g. client node's) local time and a predetermined delay, and

[0058] - broadcasting, e.g. to the processes 12 a request signal R comprising a message M and the bet B. Preferably, the request signal R may further comprise a source S of the message M, i.e. indicative of the process 12' generating the message M.

[0059] It will be appreciated that the client processes 12' or nodes 10' are not considered in the calculation of the total number N of processes 12 or nodes 10. The (client) local time can be received from a local clock 14' associated to the process 12' or node 10' .

[0060] In other words, to broadcast a message M, a client node 10' or process 12' may check the local clock and calculate a timestamp or bet B as about one message delay in the future. The bet B is thus the estimated time instant at which the receiving process 12 or node 10 will receive the request signal R, based on the calculation of the transmitting process 12' or node 10' . The request signal R can then be broadcast, with the message M associated with the bet B.

[0061] For example, the predetermined delay may be a transmission delay, e.g. the delay occurring between transmission of a signal from an originating process or node and reception of the signal by a receiving process or node .

[0062] For the purpose of the instant description, partial synchrony is considered herein: i.e. the message delay between processes is bounded by an unknown constant A; the difference between real time and the local time of any process is bound by an unknown constant W. It may be included, within the message delay, also the duration of any constant-time computing required to produce a message on the sender side or deliver a message on the receiver side. While partially synchronous algorithms often make no distinction between A and W, the availability of cheap and accurate real-time clocks, time servers, and synchronization mechanisms make the distinction relevant, as in practice W « A. In particular, even if I = A, the method described in the following may be effective and correct .

[0063] The present invention thus relates to a method of implementing a total-order or atomic broadcast in a distributed system 1 comprising a plurality of processes 12, 12' and / or nodes 10, 10' . The method comprises, see e.g. the flow chart of figure 4, a step 1000 of receiving the request signal R, e.g. sent by the client process 12' or the client node 10' , comprising the message M and the bet B, wherein the bet B is indicative of a time instant.

[0064] In particular, each message M may be associated with a respective bet B. In particular, the bet B may be indicative of a time instant by which the message M is to be delivered. Advantageously, bets provide natural ordering to messages - indeed, messages may be delivered in increasing order of bet.

[0065] The method may comprise a step 1002 of introducing the message M in an ordered set 2, the set 2 ordered as a function of increasing bet and comprising a number of messages M to be delivered in a total order.

[0066] In particular, total order means that the messages M are to be delivered in the same order across the distributed system 1 . That is , every process 12 or node 10 may deliver the same messages M in the same order .

[0067] The ordered set 2 may contain the messages M to be delivered . I f a message M is not present in the ordered set 2 , such message M will not be delivered . In particular, i f a message M is not present in the ordered set 2 , such message will not be delivered by any (non-Byzantine ) process 12 .

[0068] As exempli fied in figure 3 , three request signals may be received, with bets Bl , B2 and B3 . The bet B3 is earlier in time than bet Bl which is in turn earlier in time than bet B2 . For this reason, the messages will be ordered in the ordered set 2 as M3 , Ml and M2 .

[0069] Advantageously, thanks to the instant method, the messages may be ordered in a cost ef ficient and leaderless way . In particular, bets provide a natural total order to client-issued messages .

[0070] The method may comprise a step 1004 of delivering the message M present in the ordered set 2 associated with the lowest bet B . In the example of figure 3 , such message would be M3 having bet B3 .

[0071] In the context of the present application, the step of "delivering" a message refers to the act of ensuring that a message is ( reliably) transmitted, e . g . to a user, an application etc., in a specified order. This delivery process must guarantee that the messages are delivered in the same sequence by all non-Byzantine processes, regardless of their individual starting points or network delays .

[0072] In particular, the message M with the lowest bet B, e.g. M3, is the first in the ordered set 2. Once the message M with the lowest bet B is delivered, such message M may be deleted from the ordered set 2.

[0073] Preferably, the method may comprise delivering 1004 a message M (only) if the message M is validated. The message M is not delivered if not validated. In other words, the message M may be delivered only after a validation step occurs. That is, after being introduced in the ordered set 2, the message M may undergo validation by means of a Byzantine consensus algorithm, in particular a binary Byzantine consensus algorithm.

[0074] According to the instant invention, the ordered sets 2 of the different processes 12 in the distributed system 1 may comprise different messages M, e.g. because some messages do not reach the totality of processes or because a malicious process transmits the message only to a certain number of processes. Advantageously, thanks to the step of validating the messages in the ordered set, the validated messages delivered from the ordered set 2 can be delivered in a total order .

[0075] The method may thus comprise a step 1006 of checking, e . g . for each message present in the ordered set 2 , whether the message M is valid, e . g . i f a decision, in particular an accepting decision, is taken by means of the Byzantine consensus algorithm .

[0076] I f the message M is valid, the method may comprise delivering, 1004 , the message M . I f the message M is invalid, the method may comprise discarding or deleting, 1008 , the message M from the ordered set 2 .

[0077] Turning to the example of figure 3 , it is possible to see that the Byzantine consensus algorithm has reached a decision for messages Ml and M2 , in particular Ml is valid and M2 is invalid . As such, M2 will be deleted from the ordered set 2 without being delivered, whereas Ml is validated . No decision at that point in time is reached for M3 . As such, Ml cannot yet be delivered as a message M3 having a lower bet B3 is present in the ordered set 2 . Ml will be delivered once M3 is either validated or deleted from the ordered set 2 .

[0078] In particular, the message M may be delivered when validated i f the message M is associated with the lowest bet B in the ordered set 2 . The message M may be delivered after being validated, i f messages M with lower bets B are present in the ordered set 2 . Advantageously, this facilitates improving the property of agreement and total order. That is, the order in the set is provided by the bet B and the validation is provided by the consensus algorithm. Once the Byzantine consensus algorithm outputs validation on which messages get delivered, servers deliver said messages in increasing order of bet. If the client process 12' or node 10' underestimates the bet B and its message is rejected, the process 12' or node 10' can attempt the broadcast again with a more conservative bet. Eventually, the client process 12' or node 10' is guaranteed to disseminate its message in time.

[0079] The method may comprise, for each request signal R:

[0080] - 1010, generating a proposed binary value, e.g. 1 / 0, True / False, etc., comprising an accepting value, e.g. 1 or True, or a rejecting value, e.g. 0 or False, as a function of the bet B,

[0081] - 1012, inputting the proposed binary value into a binary Byzantine consensus algorithm configured to provide a binary decision on the proposed value by reaching an agreement between the processes 12 in the (Byzantine) distributed system 1, and

[0082] - 1014, if the decision comprises the accepting value, validating the message M in the ordered set 2.

[0083] In the context of the present invention, a "binary Byzantine consensus algorithm" refers to a method used by nodes in the distributed computing system to reach an agreement on a binary decision, such as accepting or rejecting a proposed transaction, even in the presence of Byzantine faults, e.g. faulty or malicious nodes. When implementing such algorithm, processes 12 communicate with each other, exchanging their preferences and trying to converge on a common decision D. The algorithm continues until all nodes converge to a single binary value. Overall, the binary consensus algorithm aims to ensure that all nodes in a distributed system ultimately agree on a binary decision despite potential communication delays, failures, or differing initial preferences.

[0084] Advantageously, upon receiving a request signal R, a process may decide whether the message M should be delivered by running an instance of Binary Consensus - the process proposes the accepting value (e.g. True) if it believes that the message M should be delivered, the rejecting value (e.g. False) otherwise. The proposed binary value may be calculated as a function of time and optionally source of the message, as better explained in the following.

[0085] According to one or more embodiments, the distributed system 1 may comprise a plurality of clocks 14, associated to respective processes 12. In particular, the nodes 10 may each comprise a process 12 and a respective clock 14. The clocks 14 may be indicative of a real time and / or may be at least partially synchronized throughout the distributed system 1.

[0086] The method may comprise a step 1016 of receiving (checking) a local time, e.g. of the respective clock 14. That is, the local time may be (directly) received from the clock 14, in particular the clock 14 associated with the process 12. The local time may thus be indicative of a current or real time reached by the clock 14 at a specific moment. In other words, the local time is the local time of the process 12 or node 10 in which the method is implemented .

[0087] The method may comprise generating, 1010, the proposed binary value as a function of the bet B and the local time. Optionally, the method may comprise, if the bet B is later in time with respect to the local time, generating the proposed binary value comprising the accepting value. The method may comprise, if the bet B is earlier in time with respect to the local time, generating the proposed binary value comprising the rejecting value.

[0088] Advantageously, time does not only provide a natural order for the ordered set but can also help in reaching an agreement with the other processes in the system 1.

[0089] Advantageously, in order to deliver a message, a correct process must be certain to have already delivered every message predating such message (i.e., every message whose bet is earlier than the message bet) for which Binary

[0090] Consensus could possibly decide True. To ensure this, it is not sufficient to wait for Binary Consensus to decide on all the messages that predate the considered message: the process must be convinced that, should a new message predating the considered message ever be discovered, Binary Consensus would decide to reject the predating message. Thanks to the proposed rejection of every message having bet earlier than a local time at the moment of reception of the request signal, agreement is not broken.

[0091] According to one or more embodiments, the method may comprise a step 1018 of periodically broadcasting the local time thereof, e.g. of the (respective) clock 14. That is, the processes 12 may broadcast the local time thereof, in particular received (directly) from the respective clock 14. Each process 12 or node 10 in the system 1 may be configured to periodically broadcast its local time to the remaining processes 12 or nodes 10 in the distributed system 1.

[0092] Optionally, the method may comprise broadcasting 1018 the local time when the local time reaches the bet B, e.g. if the bet B at reception is later than the local time.

[0093] This may occur for each request signal R and / or each bet B present in the ordered set 2. That is, for any bet, the method may comprise broadcasting 1018 the local time when the local time reaches such bet.

[0094] Optionally, the method comprises a step 1020 of receiving remote times from the plurality of processes 12, the remote times indicative of local times of the (remaining) plurality of processes in the system 1.

[0095] That is, the remote times may be indicative of the time read in the plurality of clocks 14 associated with the remaining processes 12 or nodes 10 in the system 1. The remote times may be received e.g. via the distributed network .

[0096] The method may comprise a step 1022 of setting a lock time as a function of the received remote times and / or the local time, e.g. both the local time received from the respective clock 14 and the local times of the remaining processes 12 via the distributed network. The lock time may be indicative of a (greatest or latest) time instant reached at least by a predetermined number of processes 12. An updated lock time is later in time than a previous lock time, i.e. the lock times are in increasing chronological order.

[0097] It will be appreciated that the steps 1020 and 1022 are, for the sake of simplicity and conciseness, depicted only once in the flow chart of figure 4. However, such steps can occur for multiple times during the steps of the method depicted in figure 4 . That is , the lock time can be calculated multiple times or at di f ferent steps during the method .

[0098] According to one or more embodiments , the predetermined number is calculated as a function of the total number N of processes 12 in the distributed system 1 and / or the predetermined number is an odd number . In particular, the predetermined number is 4 * f + 1 , wherein and N is a total number of processes in the Byzantine system, and wherein floor ( ) is the mathematical floor function that takes as input a real number x, and gives as output the greatest integer less than or equal to x, denoted floor (x ) . In particular, the predetermined number can be about 80% of the total number of processes in the Byzantine system .

[0099] Thanks to the lock time , the method may comprise introducing, 1002 , the message M in the ordered set 2 i f ( and only i f ) the bet B is later than the lock time , in particular i f the bet B is later than the lock time when the request signal R is received . That is , the bet B is later than the lock time set at reception of the request signal R .

[0100] I f , when the request signal R is received, the lock time is later in time than the bet B, the message M is not introduced into the ordered set 2 and preferably deleted.

[0101] Thanks to the lock time, the method may comprise delivering, 1004, the message M present in the ordered set 2 associated with the lowest bet, if validated and if the lock time reaches the bet B, i.e. if the lock time is equal to or later in time with respect to the bet B.

[0102] At any point in time, the lock time is defined as the highest local time reached by at least the predetermined number of processes 12, e.g. 4f +1. The ordered set 2 may contain every message having, at reception, bet later in time with respect to the lock time. It is possible to ascertain that no new messages, having a bet lower than the lock time, would ever be introduced in the ordered set .

[0103] By definition, by the time the lock time reaches a certain time instant tl, all elements of the ordered set 2 having bet smaller than tl are received. As such, once the lock time reaches tl, the validated messages within the set 2 having bet earlier than tl can be confidently delivered, in increasing order of bet. Any new message having bet B predating tl will certainly be rejected by all correct processes 12 in the system 1.

[0104] According to one or more embodiments, the method may comprise receiving, 1000, the request signal R comprising the message M, the bet B and a source S of the message M and / or request signal R, wherein the source S is indicative of a process 12' generating the message M and / or request signal R. That is, the source S is indicative of the origin of the message M and / or request signal R.

[0105] The method may further comprise a step of broadcasting the request signal R. Accordingly, the request signal R may be received from the source S, e.g. client process 12' or node 12' , and / or from processes 12 in the distributed system 1, that are not the source S.

[0106] In particular, the request signal R may be propagated or broadcast upon receival, e.g. independently of the source S of the request signal, i.e. independently of whether the request signal R is received directly from the source S of the request signal R / message M or a different process 12.

[0107] Advantageously, this allows to satisfy the property of convergence, in that each process 12 may propose a value to the Byzantine consensus algorithm, even if - due to faults or malicious processes - a process 12 might not receive the message from the source S.

[0108] Accordingly, the method may comprise generating, 1010, the binary value as a function of the source S.

[0109] Preferably, if the request signal R is received from the source S and the bet B is later in time than the local time, e.g. read from the respective clock 14, generating, 1010, the binary value as the accepting value. In particular, in this case, the binary value may be generated, 1010, when the request signal R is received, in particular immediately after receiving the request signal R.

[0110] Preferably, if the request signal R is not received from the source S and the local time, e.g. read from the respective clock 14, reaches the bet B, generating, 1010, the binary value as the rejecting value. In particular, the binary value may be generated, 1010, when the local time reaches the bet B.

[0111] Advantageously, if the local time reaches the bet of some message for which no proposed binary value has been generated yet, the method may comprise generating the proposed binary value as the rejecting value. This condition is triggered only if the request signal R is received only by another process 12 and not from a client process 12' or node 10' . In that case, the source was not authenticated and thus an accepting value cannot be proposed. To ensure liveness, however, every correct process must submit a proposal to every Consensus instance.

[0112] Advantageously, generating the proposed binary value as a function of the source may facilitate ensuring the property of integrity.

[0113] According to the present invention and application filed by the same Applicant on the same day as the instant application, in the good case, i.e. in case clocks are well-synchronized and the network is synchronous, it is possible to obtain a Byzantine consensus and Total-Order Broadcast is little more than two message delays, in particular (2A + e) time units, with e being an arbitrary small constant.

[0114] In particular, see e.g. figure 5 depicting a good case scenario, the method may comprise, in addition to the steps of generating, 1010, the proposed binary value and inputting, 1012, the proposed binary value into the binary Byzantine consensus algorithm:

[0115] - broadcasting, 1024, a suggestion signal comprising the proposed binary value associated with the request signal R, e.g. towards all processes 12 in the distributed system 1,

[0116] - receiving, 1026, a plurality of suggestion signals, e.g. from the remaining processes 12 in the distributed system 1, the suggestion signals indicative of the proposed binary value associated with the request signal R.

[0117] Optionally, the method may comprise, when the received suggestion signals having the same binary value reach the predetermined number, identifying, 1028, such shared binary value as the binary decision of the binary Byzantine consensus algorithm. The method may comprise identifying the shared binary value as the binary decision before receiving the binary decision from the Byzantine consensus algorithm. Advantageously, this may effectively reduce the time needed to reach a consensus decision. The method may comprise: if the shared binary value is an accepting value, validating, 1014, the message M in the ordered set 2, and / or if the shared binary value is a rejecting value, discarding or deleting 1008 the message M from the ordered set 2.

[0118] In particular, the predetermined number may be calculated as a function of a total number N of processes 12 in the distributed system 1 (e.g. excluding client nodes 10' or client processes 12' ) and / or the predetermined number is an odd number. Preferably, the predetermined number is 4*f + 1, wherein and N is the total number of processes 12 in the distributed system 1 and / or the predetermined number is about 80% of the total number N of processes 12 in the distributed system 1.

[0119] Optionally, the method may further comprise, when a total number of received suggestion signals reaches the predetermined number, generating, 1010, the proposed binary value also as a function of the received suggestion signals. In particular, the method may comprise identifying within the received suggestion signals which is the most represented value between the first and second value, and generating the proposed binary value as the most represented value.

[0120] In the good case, clocks are well-synchronized and the network is synchronous. When broadcasting the message M at a certain time t, process 12' can thus set a bet B = t + A + e. By time (t + A) , every correct server 12' receives the request signal R and proposes that the message M should be delivered. This unlocks the fast path: because every correct server proposes the same value, every correct server decides that the message M should be delivered within one message delay, i.e., by time (t + 2A) . By time (t + 2A + e) , every correct process can be certain to not have missed any message with a lower bet than B, and delivers the message M. This is because the lock time has reached the time of bet B, and thus no new message predating B will be added to the ordered set 2. As such, every message that might receive an accepting decision from the binary consensus is already in the ordered set, and the method may comprise receiving the decisions on the messages and delivering the validated messages in increasing order of bet.

[0121] In particular, figure 2 depicts such good-case latency .

[0122] For example, in the good case, clocks are synchronized and A is known . This means that the client estimate in the bet B is accurate . At a certain time tO , the client broadcasts the request signal R with bet B = tO + A + e .

[0123] At time tl = ( tO + A ) , every correct server receives and proposes delivering the message M .

[0124] At time ( tO + A + e) , every correct server announces its time being exactly ( tO + A + e) . Because every correct server proposes the same value , every correct server fastpath decides to deliver M by time t2 = ( tO + 2A ) .

[0125] At time ( tO + 2A + e) , every correct server' s lock time reaches the bet B = ( tO + A + e) , and every correct server delivers the message M .

[0126] The present invention may also relate to a computer program product loadable in the memory of at least one electronic processing unit , for example an electronic processing unit of a node 10 , and comprising software code portions suitable for performing the steps of the method according to one or more embodiments as described above .

[0127] In other words , the present invention may relate to a computer program product comprising a non-transitory computer-readable medium storing instructions that , when executed by a processor of a computing device , cause the computing device to perform the steps of the method according to one or more embodiments .

Claims

Claims1. A method of implementing a total-order broadcast in a distributed system (1) comprising a plurality of processes (12) , the method comprising:- receiving (1000) a request signal (R) comprising a message (M) and a bet (B) , wherein the bet (B) is indicative of a time instant, and- introducing (1002) the message (M) in an ordered set (2) , the set (2) ordered as a function of increasing bet (B) and comprising a number of messages (M) to be delivered in a total order.

2. The method according to the preceding claim, comprising delivering (1004) the message (M) present in the ordered set (2) associated with the lowest bet (B) , if validated (1014) .

3. The method according to claim 1 or claim 2, comprising, for each request signal (R) : generating (1010) a proposed binary value comprising an accepting value or a rejecting value as a function of the bet (B) ,- inputting (1012) the proposed binary value into a binary Byzantine consensus algorithm configured to provide a binary decision on the proposed binary value by reachingan agreement between the processes (12) in the distributed system ( 1 ) , and if the decision comprises the accepting value, validating (1014) the message (M) in the ordered set (2) .

4. The method according to the preceding claim, comprising :- receiving (1016) a local time,- generating (1010) the proposed binary value as a function of the bet (B) and the local time,- preferably, if the bet (B) is later in time with respect to the local time, generating (1010) the proposed binary value comprising the accepting value, and / or, if the bet is earlier in time with respect to the local time, generating (1010) the proposed binary value comprising the rejecting value.

5. The method according to any of the previous claims, comprising periodically broadcasting (1018) a local time, preferably comprising broadcasting (1018) the local time when the local time reaches the bet (B) .

6. The method according to any of the previous claims, comprising :- receiving (1020) remote times from the plurality ofprocesses (12) , the remote times indicative of local times of the plurality of processes (12) , and- setting (1022) a lock time as a function of the received remote times and preferably the local time, the lock time indicative of a time instant reached at least by a predetermined number of processes (12) .

7. The method according to the previous claim, comprising at least one of:- introducing (1002) the message (M) in the ordered set (2) if the bet (B) is later than the lock time, preferably if the bet (B) is later than the lock time set at reception of the request signal (R) , and / or- delivering (1004) the message (M) present in the ordered set (2) associated with the lowest bet, if validated and if the lock time reaches the bet (B) .

8. The method according to any of the previous claims, comprising :- receiving (1000) the request signal (R) comprising the message (M) , the bet (B) and a source (S) of the message (M) , wherein the source (S) is indicative of a process (12' ) generating the message (M) , and- generating (1010) the proposed binary value also as a function of the source (S) ,- preferably, if the request signal (R) is received from the source (S) and the bet (B) is later in time than a local time, generating (1010) the proposed binary value as the accepting value, and / or preferably, if the request signal (R) is not received from the source (S) and the local time reaches the bet (B) , generating (1010) the proposed binary value as the rejecting value.

9. A computer program product loadable in the memory of at least one electronic processing unit, for example of a node (10) , and comprising software code portions suitable for performing the steps of the method according to any of the previous claims.

10. A node (10, 10' ) connectable to a distributed system (1) , the node (10, 10' ) comprising at least one electronic processing unit configured for performing the steps of the method of any of claims 1-8 and / or for:- calculating a bet (B) as a sum between a local time and a predetermined delay, preferably a transmission delay, and- broadcasting a request signal (R) comprising a message (M) , the bet (B) and preferably a source (S) of the message (M) .

11. A distributed system (1) , comprising a plurality of processes (12) , the processes (12) being configured to perform the steps of the method according to any of claims 1-8.

Images