Efficient reliable broadcast

Abstract

Embodiments of the invention relate to a method for broadcasting a message in a distributed network. The distributed network comprises a set of n nodes, wherein for a respective broadcast the set of nodes is split into a sender node and set of n-1 receiver nodes, wherein at most t nodes of the set of nodes are Byzantine nodes, wherein t and n are integers and t < (n / 3). The method comprises encoding the message into n encoded fragments by a (n, n-t) erasure code and allocating each fragment of the n encoded fragments to one corresponding node of the set of nodes. Further steps include transmitting, by the sender node, to each node of the set of n-1 receiver nodes its allocated fragment, broadcasting, by each node its allocated fragment to the set of receiver nodes and reconstructing, upon receipt of (n-t) fragments, the message. An additional step includes checking, by each of the receiver nodes, whether it has received from each of the other n-2 receiver nodes of the set of receiver nodes its allocated fragment and, if there are one or more missing fragments from one or more of the other n-2 receiver nodes, sending, by the respective receiver node, the one or more missing fragments to the corresponding one or more receiver nodes from which their respective allocated fragment has not been received. Further aspects relate to a distributed network, a node of a distributed network and a corresponding computer program product.

Description

[0001]Efficient reliable broadcast Technical Field The present invention pertains to a method for broadcasting a message in a distributed network. Further aspects relate to a distributed network, a node of a distributed network and a corresponding computer program product. Background Art The goal of Byzantine reliable broadcast is to disseminate a message efficiently and reliably despite the presence of Byzantine nodes that may interfere with the protocol execution in arbitrary ways. A reliable broadcast routine is a powerful primitive with a broad range of applications including asynchronous atomic broadcast, distributed key generation, secure data replication and secret sharing. Moreover, reliable broadcast plays a pivotal role in Byzantine fault-tolerant consensus protocols where message dissemination is treated separately from message ordering to improve throughput. The first Byzantine reliable broadcast algorithm was disclosed by Bracha in the document "Asynchronous Byzantine Agreement Protocols; Information and Computation 75, 2 (1987), 130–143.". While it is error-free and elegant in its simplicity, its main drawback is that the message is broadcast by every node during the execution of the algorithm. In the document by Cachin and Tessaro, "Asynchronous Verifiable Information Dispersal; Proc. 24th MIM 09.04.2024 P192665PC00 IEEE Symposium on Reliable Distributed Systems (SRDS). 191– 201", this bound was improved by using erasure coding. One remaining challenge of such broadcast schemes is the question whether a further reduction of the communication complexity is possible without loss of security. Disclosure of the Invention Accordingly, one object of an aspect of the invention is to provide an improved method for broadcasting data, in particular messages, in a distributed network, in particular in terms of communication and computational complexity. According to an embodiment of an aspect of the invention, a method for broadcasting a message in a distributed network is provided. The distributed network comprises a set of n nodes. The set of nodes may be split for a respective broadcast into a sender node and set of n-1 receiver nodes, wherein at most t nodes of the set of nodes are Byzantine nodes. Herein t and n are integers and t < (n / 3). The method comprises steps of encoding the message, by the sender node, into n encoded fragments by a (n, n-t) erasure code and allocating, by the sender node, each fragment of the n encoded fragments to one corresponding node of the set of nodes including the sender node itself. Hence each node of the set of nodes has one different allocated fragment. As a further step the sender node transmits to each node of the set of n-1 receiver nodes its respective allocated fragment. After this step each node of the set of nodes is in the possession of one allocated fragment of the message. A further step includes broadcasting, by each node of the set of nodes, its MIM 09.04.2024 P192665PC00 respective allocated fragment to the set of receiver nodes. By this step the fragments are distributed by broadcasting to the set of receiver nodes. This step may include according to embodiments that the receiver nodes also send their allocated fragments to the sender node, but as the sender node is already in the possession of all fragments, this is optional. Further steps include reconstructing, by the respective receiver node, upon receipt of (n-t) fragments, the message. An additional step includes checking, by each of the receiver nodes, whether it has received from each of the other n-2 receiver nodes of the set of receiver nodes its allocated fragment. If there are one or more missing fragments from one or more of the other n-2 receiver nodes, i.e. if one or more of the receiver nodes have not broadcast their allocated fragments, a further step includes transmitting, by the respective receiver node, the one or more missing fragments to the corresponding one or more receiver nodes from which their respective allocated fragment has not been received. With the latter step it can be ensured that each node of the set of nodes, in particular of the set of receiver nodes, will finally receive its allocated fragment and can finally reconstruct the message. The latter step ensures in particular that each of the receiver nodes receives its allocated fragment in scenarios where the sender node is faulty or Byzantine. Optionally, it may also be checked whether the sender node has sent its allocated fragment and if this is not the case, the receiver nodes may provide the missing fragment to the sender node. Such a method ensures a broadcast of the message in a reliable and efficient way even in the case that t nodes are Byzantine and hence may interfere with MIM 09.04.2024 P192665PC00 the underlying broadcast protocol in an arbitrary way. Furthermore, such a method lowers the communication and computational complexity of the broadcast compared with known methods. More particularly, the use of a (n, n-t) or in other words a (n, 2t+1) erasure code for n=3t+1 reduces the coding overhead to n / (2t+1) < 3 / 2. This modification reduces the cost of broadcasting fragments. However, correctness would no longer be given without additional changes because some nodes may receive (n-t) fragments, whereas others merely obtain t + 1 fragments which is not enough to recover the message. This problem is addressed according to embodiments of the invention by the additional step of sending missing fragments. More particularly, if a node manages to reconstruct the message, it disseminates fragments again but only to the t nodes from which no fragment was received. Investigations of the inventor of the present invention have shown that this additional measure is sufficient to ensure correctness while keeping the communication complexity low. As an added benefit, the transition from a (n, t + 1)-erasure code to a (n, 2t + 1)-erasure code results in substantial performance improvements, both with respect to the encoding and decoding of fragments. According to an embodiment, an authenticated communication channel is provided for the communication between the set of nodes.This ensures that the communication is resistant to tampering. According to embodiments, the method further comprises waiting for a predetermined time interval before sending the one or more missing fragments. This may avoid sending the missing fragments unnecessarily in case of late arrivals. According to embodiments, a timer MIM 09.04.2024 P192665PC00 may be used which may be triggered e.g. by the receipt of the first fragment. According to embodiments, the erasure code is an erasure code with optimal reception efficiency. Such erasure codes have the property that any k out of the n code word symbols are sufficient to recover the original message. According to embodiments, the erasure code may be a Reed–Solomon code or an Erasure Resilient Systematic Code. According to an embodiment, the transmitting of its allocated fragment comprises transmitting an execution identifier, a root hash and a Merkle proof with respect to its allocated fragment and the root hash. This is an efficient method to enable the receiver nodes to verify the validity of a received fragment. The root hash is assumed to be cryptographically strong in the sense that it is infeasible to find hash collisions. More particularly, each of the receiver nodes may perform, upon receipt of a fragment from the sender node or any of the other n-2 receiver nodes, a verification of the received fragment by means of the root hash and the Merkle proof. It may then store or in other words collect the received fragment only upon successful verification. This avoids storing faulty fragments. The execution identifier facilitates an efficient use of the network. More particularly, the method may be performed in parallel for a plurality of messages having different execution identifiers. According to embodiments, a receiver that has received n-t fragments, i.e., a sufficient number of fragments for reconstruction, may verify, after reconstructing the message, whether the received (n-t) fragments are consistent with the root hash of the MIM 09.04.2024 P192665PC00 reconstructed message. This allows a verification of the complete message. According to embodiments, the method may include performing, by the set of nodes, a support protocol for collecting support messages for a respective root hash for a respective execution identifier and performing, by each node of the set of nodes, the step of broadcasting its allocated fragment once a predefined support criteria has been met for the root hash of the execution identifier. Such a support protocol provides an efficient use of the network resources. In particular it avoids broadcasting fragments that do not have enough support. The respective support criteria may be defined in dependence on the chosen support protocol. According to embodiments, the method may include broadcasting, upon receipt of its allocated fragment, by each of the nodes, a proposal comprising the execution identifier and the root hash of the received fragment and performing, by each node of the set of nodes, the step of broadcasting its allocated fragment once a predefined number of corresponding or matching proposals of the other nodes has been received for its allocated fragment. By introducing the round of proposals endorsing a particular root hash, integrity may be guaranteed. Furthermore, as proposals may be significantly smaller than fragments, they use significantly less communication resources of the network. Accordingly, such proposals serve to keep the communication complexity low. According to embodiments, the method may further comprise broadcasting, by each of the receiver nodes, upon receipt of t+1 fragments for a respective root hash, a proposal comprising the execution identifier and MIM 09.04.2024 P192665PC00 the root hash if the corresponding proposal has not been sent before. If a node has received t+1 fragments for a root hash, this indicates that at least one honest node has received n-t proposals for the root hash and then broadcast its allocated fragment. This indicates that the corresponding root hash is supported by n-t nodes and hence trustworthy. Hence the node can safely support the proposal, even if it has never received its allocated fragment from the sender. According to another embodiment, the method may comprise executing, by each of the nodes, upon receipt of its allocated fragment, a threshold signature on a tuple comprising the execution identifier and the root hash of its allocated fragment. A further step includes broadcasting, by each of the nodes, the respective threshold-signed tuple. According to a preferred embodiment, the broadcasting of the threshold-signed tuple may be performed together with its corresponding fragment. Hence according to such an embodiment, the fragments are broadcast right away after receipt by a respective node together with the threshold signed tuple. This provides a better time complexity compared with the embodiment where proposals to agree on a root hash are sent first before broadcasting the fragments. More particularly, such an embodiment may provide an optimal time complexity of 2. However, if fragments are broadcast right away, a Byzantine sender can cause havoc by sending fragments for different root hashes to different nodes. Hence if honest nodes simply broadcast any received fragments, this would have an adverse effect on the communication complexity. MIM 09.04.2024 P192665PC00 This problem is elegantly solved by using the threshold signed tuples. According to embodiments, a node executes, upon collection of n-t signed tuples, a multi-signature on the tuple and broadcasts the tuple signed with the multi- signature. Such a multi-signature combines n-t threshold signatures into a compact signature. The multi-signature may then serve as a proof that the respective node that broadcasts it has received threshold signatures from n-t nodes. Accordingly, a node that receives a multi-signature can make progress, i.e. deliver the corresponding message. According to embodiments, each of the receiver nodes may perform a check if it has received (n-t) tuples for a root hash for which it has not yet broadcast a signed tuple and its own individual allocated fragment. If this holds true and its own individual allocated fragment is available, the respective node broadcasts its own individual allocated fragment. Such an embodiment addresses scenarios in which a sender node has sent a faulty tuple with a wrong root hash to one or more of the receiver nodes. As soon as a respective receiver node has received (n-t) tuples for the correct hash, it can recognize that the root hash and the corresponding fragment that were received before were wrong. Accordingly, it may then support the correct root hash in the future by broadcasting its own individual allocated fragment corresponding to the correct root hash once it is available. In such a scenario the respective receiver node may have received its own individual allocated fragment corresponding to the correct root hash from one of the other honest receiver nodes. MIM 09.04.2024 P192665PC00 According to an embodiment of another aspect of the invention, a distributed network is provided. The distributed network may be configured to perform steps of the method aspect of the invention. According to an embodiment of another aspect of the invention, a node of a distributed network is provided. The node may be configured to perform steps of the method aspect of the invention. More particularly, the node may be configured to act as receiver node or as a sender node and perform the corresponding steps of the sender node or the receiver node, in dependence of its respective role. According to an embodiment of another aspect of the invention, a computer program product for operating a distributed network is provided. The computer program product comprises a computer readable storage medium having program instructions embodied therewith, the program instructions executable by one or more of a plurality of nodes of the distributed network to cause the one or more of the plurality of nodes to perform steps of the method aspect of the invention. Features and advantages of one aspect of the invention may be applied to the other aspects of the invention as appropriate. Other advantageous embodiments are listed in the dependent claims as well as in the description below. Brief Description of the Drawings The invention will be better understood and objects other than those set forth above will become MIM 09.04.2024 P192665PC00 apparent from the following detailed description thereof. Such description makes reference to the annexed drawings, wherein: FIG. 1 shows a distributed network according to an embodiment of the invention; FIGS. 2a, 2b and 2c illustrate an example of a message flow for a communication of a message within the distributed network according to FIG. 1 with an honest sender node; FIGS. 3a, 3b, 3c, 3d and 3e illustrate an example of a message flow for a communication of a message within the distributed network according to FIG. 1 with a Byzantine sender node; FIG. 4a shows a flow chart comprising a main flow of steps of a method for broadcasting a message in a distributed network according to an embodiment of the invention; FIG. 4b shows a more detailed flow chart with some sub-steps which may be added to the main flow of steps shown in FIG. 4a according to an embodiment of the invention; FIG. 4c shows a more detailed flow chart with some sub-steps which may be added to the main flow of steps shown in FIG. 4a according to another embodiment of the invention; FIG. 5 shows an exemplary embodiment of a node according to an embodiment of the invention; and Fig. 6 shows performance numbers when encoding / decoding a message of size 1MiB for various network sizes and two different parameterizations. Modes for Carrying Out the Invention MIM 09.04.2024 P192665PC00 At first, some general aspects and terms of embodiments of the invention will be introduced. According to embodiments, a distributed network comprises a plurality of nodes that are arranged in a distributed fashion. In such a distributed network, computing, software and data is distributed across the plurality of nodes. The nodes establish computing resources and the distributed network may use in particular distributed computing techniques. According to embodiments, distributed networks may be embodied as blockchain networks. The term <blockchain= shall include all forms of electronic, computer- based, distributed ledgers. According to some embodiments, the blockchain network may be embodied as a proof-of-work blockchain network. According to other embodiments, the blockchain network may be embodied as a proof-of-stake blockchain network. Communication complexity of a broadcast protocol: The number of bits that need to be exchanged in the worst case. Byzantine node: A node that may interfere with the execution of any given protocol, in particular a communication protocol, in arbitrary ways. Honest node: A node that faithfully executes the given protocol. Sender node: A node of a distributed network that initiates the sending of a message by means of a communication protocol to all other nodes of the network called receiver nodes. During the performance of the communication protocol for a respective message, the sender node and the receiver nodes keep their role. However, the receiver nodes may also send or broadcast fragments, proposals, signed tuples and other message MIM 09.04.2024 P192665PC00 elements during execution of the communication protocol. Furthermore, the sender node performs several steps of the receiver nodes during the performance of the communication protocol in the same or a similar manner as the receiver nodes. Byzantine reliable broadcast protocol: Generally a protocol for broadcasting a message in a distributed network efficiently and reliably despite the presence of Byzantine nodes that may interfere with the protocol execution in arbitrary ways. More particularly a reliable broadcast protocol configured to send a message m from a specific node called the sender node to all other nodes of the network called receiver nodes with the following properties: Validity: If the sender is honest and broadcasts message m, then every honest node eventually delivers m. Agreement: If two honest nodes deliver messages m and m′, then m = m ′. Integrity: Every honest node delivers at most one message m. Totality: If an honest node delivers message m, then all honest nodes eventually deliver m. A distributed network according to embodiments of the invention is considered to comprise n = 3t + 1 nodes, where t denotes the (maximum) number of Byzantine nodes, which may deviate arbitrarily from any given protocol. The other 2t + 1 nodes are honest nodes. This notation is equivalent to defining that (n-t) nodes are honest, while n < (n / 3). In other words, less of a third of the nodes are Byzantine. MIM 09.04.2024 P192665PC00 Asynchronous communication: A communication within a distributed network, wherein the delivery of messages, while guaranteed, may be delayed indefinitely. Hence in an asynchronous communication model, the nodes cannot make any assumption about message delays, neither about the time required until a sent message arrives at its destinations nor about the time that elapses until certain (expected) messages are received. Broadcast by a sender node: The sender node sends a message, fragments of a message or other communication elements to all other nodes of the network by means of a communication protocol. This may include sending the message or the fragment to the sender node itself. Broadcast by a receiver node: The receiver node sends the fragment, proposal, signed tuple, multi- signature or other communication elements at least to the other receiver nodes, and optionally also to the sender node. Unicast: A node sends a message to one single node of the distributed network Hash tree: A hash tree may also be denoted as Merkle-tree and was originally described by Ralph Merkle in Merkle, R. C. (1988). "A Digital Signature Based on a Conventional Encryption Function". Advances in Cryptology — CRYPTO '87. Lecture Notes in Computer Science. 293. pp. 369–378. A hash tree may be generally described as a tree in which every leaf node is labelled with the cryptographic hash of data elements and every non-leaf node is labelled with the cryptographic hash of the labels of its child nodes. Hash trees may be considered as a generalization of hash lists and hash chains. MIM 09.04.2024 P192665PC00 Multi-signature: A multi-signature is a compact representation of multiple signatures of multiple signers. A multi-signature is in particular more compact in size (in bytes) than the size (in bytes) of a collection of distinct signatures of the multiple signers. Threshold Signature:In a (n,t) threshold public key signature scheme, any t secret key shares enable the execution of a valid signature under the threshold public key / verification key, while t-1 shares do not suffice to execute a valid signature. Erasure code: An error correction code under the assumption of bit erasures which transforms a message of k symbols into a longer message (code word) with n symbols such that the original message can be recovered from a subset of the n symbols. (^,^)-erasure code with optimal reception efficiency: A code where exactly ^ out of ^ symbols are sufficient to reconstruct a message of ^ symbols. A fragment of a message ^: anencoding of parts of the message ^. | ^ | denotes the size of ^ in bytes. A missing fragment: A fragment of a message m allocated to a respective receiver node of a set of n-1 receiver nodes that has not yet been received by one or more of the other n-2 receiver nodes during the execution of the broadcast protocol. FIG. 1 shows a distributed network 100 according to an embodiment of the invention. The distributed network 100 comprises a plurality of nodes 10, which may also be denoted as network nodes 10. The set of nodes may communicate with each other via communication MIM 09.04.2024 P192665PC00 channels 11. The communication channels 11 may be in particular authenticated channels for performing an authenticated communication. According to this exemplary embodiment, the distributed network 100 comprises a set of n=7 nodes. More particularly, the set of nodes comprises the nodes N1, N2, N3, N4, N5, N6 and N7. In general, it is assumed that at most t nodes of the set of n nodes are faulty nodes, in particular Byzantine nodes, wherein t and n are integers. Furthermore, t < (n / 3), i.e. less than a third of the nodes are Byzantine nodes. Accordingly, in the exemplary embodiment as illustrated in FIG. 1, at most two of the n=7 nodes are Byzantine nodes. According to embodiments, messages m may be broadcast between the nodes 10 of the set of nodes. For a respective broadcast the set of nodes may be split into a sender node and a set of n-1 receiver nodes. FIGS. 2a, 2b and 2c illustrate an example for such a communication of a message m. For the illustrated example it is assumed that the node N1 acts as sender node S, while the nodes N2-N6 form a set of n-1=6 receiver nodes. Furthermore, it is assumed that the nodes N6 and N7 are Byzantine nodes B, which is indicated in addition by a dotted ring. According to the embodied communication scheme, the sender node N1 encodes the message m into n encoded fragments by a (n, n-t) erasure code. Accordingly, in this example the sender node N1 encodes the message m into 7 fragments f1, f2, f3, f4, f5, f6 and f7, wherein 5 fragments are sufficient to reconstruct the message m. MIM 09.04.2024 P192665PC00 Furthermore, the sender node N1 allocates each fragment of the n encoded fragments to one corresponding node of the set of nodes including the sender node itself. Accordingly, the fragments f1, f2, f3, f4, f5, f6 and f7 are allocated to the nodes N1, N2, N3, N4, N5, N6 and N7 respectively. Then, as illustrated in FIG. 2a, the sender node N1 transmits / sends to each node of the set of n-1 receiver nodes its allocated fragment by a corresponding unicast message. Accordingly, the sender node N1 sends the fragments f2, f3, f4, f5, f6 and f7 to the nodes N2, N3, N4, N5, N6 and N7 respectively. In a generalized example this may include transmitting the fragment f1 to the sender node N1 itself. At a further step as illustrated in FIG. 2b, each honest node of the set of nodes, broadcasts its allocated fragment at least to the set of receiver nodes. As in this example it is assumed that the nodes N6 and N7 are Byzantine nodes, only the honest nodes N1, N2, N3, N4 and N5 broadcast their allocated fragments f1, f2, f3, f4 and f5 respectively. It should be noted that according to embodiments the (honest) receiver nodes N2, N3, N4 and N5 may also send their respective fragments f2, f3, f4 and f5 to the sender node N1, but as the sender node N1 already has the message and the fragments, this is optional. As according to the example illustrated in FIGS. 2a and 2b the sender node is honest (non-Byzantine and not faulty), each of the honest nodes N1, N2, N3, N4 and N5 are in the possession of the five fragments f1, f2, f3, f4 and f5 and are hence in the position to reconstruct the fragment. Accordingly, as a next step the receiver nodes N2, N3, N4 and N5 may reconstruct the message m. After the reconstruction of the message, in general each of the receiver nodes checks whether it has MIM 09.04.2024 P192665PC00 received from each of the other n-2 receiver nodes of the set of receiver nodes its allocated fragment. According to this example, at least the receiver nodes N2, N3, N4 and N5 perform this check and will note that the fragment f6 of node N6 and the fragment f7 of node N7 is missing. In order to ensure that all (honest) nodes receive the broadcast message m, the nodes N2, N3, N4 and N5 send the missing fragments f6 and f7 to the receiver nodes N6 and N7 respectively. Optionally also the sender node N1 may send the missing fragments f6 and f7 to the receiver nodes N6 and N7 respectively, although it is aware that it has already sent it before. In the scenario as illustrated in FIGS. 2a- 2c, the sender node N1 is honest. Accordingly, the honest nodes N1-N5 are already after the step of broadcasting the individual fragments by the nodes N1-N5 in the possession of (n-t) valid fragments. Such a scenario of an honest sender node is usually considered less critical than a scenario where the sender node is Byzantine. FIGS. 3a to 3e illustrate now an example according to embodiments of the invention in which the sender node N1 is Byzantine. For the illustrated example it is assumed that the node N1 acts as sender node S and is a Byzantine node B, while the nodes N2-N6 form a set of n-1=6 receiver nodes. Furthermore, it is assumed that the receiver node N7 is a Byzantine node B. This is again indicated in addition by a dotted ring. According to the embodied communication / broadcast scheme, the Byzantine sender node N1 encodes the message m into n encoded fragments by a (n, n-t) erasure code. Accordingly, in this example the sender node N1 encodes the message into 7 fragments f1, f2, f3, MIM 09.04.2024 P192665PC00 f4, f5, f6 and f7, wherein 5 fragments are sufficient to reconstruct the message m. Furthermore, the sender node N1 allocates each fragment of the n encoded fragments to one corresponding node of the set of nodes including the sender node itself. Accordingly, the fragments f1, f2, f3, f4, f5, f6 and f7 are allocated to the nodes N1, N2, N3, N4, N5, N6 and N7 respectively. Then, as illustrated in FIG. 3a, the Byzantine sender node N1 sends (on purpose) only the four fragments f2, f3, f4 and f5 to the nodes N2, N3, N4, N5, while it does according to its Byzantine behavior not send the fragments f6 and f7 to the nodes N6 and N7 respectively. At another step as illustrated in FIG. 3b, each (honest) node of the set of nodes broadcasts its allocated fragment (if already received) at least to the set of receiver nodes. As in this example it is assumed that the nodes N1 and N7 are Byzantine nodes, only the honest nodes N2, N2, N3, N4 and N5 broadcast their allocated fragments f2, f3, f4 and f5 respectively. Node N6, although honest, has not received its fragment f6 yet. Furthermore, the Byzantine sender node N1 sends its allocated fragment f1 on purpose only to node N2, but not to the other nodes N3- N7. As a result, as illustrated in FIG. 3c, only the node N2 has received the minimum number of five fragments required for recovery, namely the fragments f1, f2, f3, f4 and f5, while the other honest nodes N3, N4, N5 and N6 have only the fragments f2, f3, f4 and f5. In the illustration of FIGS. 3c to 3e, the fragments which have been collected by the receiver nodes are shown in a corresponding cylinder. Accordingly, as a next step only the receiver node N2 may reconstruct the message m. MIM 09.04.2024 P192665PC00 After the reconstruction of the message m, the receiver node N2 checks whether it has received from each of the other n-2 receiver nodes of the set of receiver nodes its allocated fragment and will note that the fragment f6 of node N6 and the fragment f7 of node N7 is missing. In order to ensure that all honest nodes receive the broadcast message m, the node N2 sends the missing fragments f6 and f7 to the receiver nodes N6 and N7 respectively. The result is shown in FIG. 3d. Referring to FIG. 3d, as node N6 has now finally received its allocated fragment f6, it broadcasts its allocated fragment f6 at least to the set of receiver nodes, and optionally also to the sender node N1. Furthermore, honest node N6 has received the minimum number of five fragments required for recovery, namely the fragments f2, f3, f4, f5 and f6. Accordingly, the node N6 may reconstruct the message m. After the reconstruction of the message, the receiver node N6 checks whether it has received from each of the other n-2 receiver nodes of the set of receiver nodes its allocated fragment and will note that the fragment f7 of node N7 is missing. In order to ensure that all honest nodes receive the broadcast message m, the node N6 sends the missing fragment f7 to the receiver node N7. Due to the broadcast of the fragment f6 by node N6, the receiver nodes N3, N4 and N5 have then, as shown in FIG. 3e, also received the minimum number of five fragments required for recovery, namely the fragments f2, f3, f4, f5 and f6. Accordingly, the nodes N3, N4 and N5 may reconstruct the message m. After the reconstruction of the message m, the receiver nodes N3, N4 and N5 check whether they have received from each of the other n-2 receiver nodes of the set of receiver nodes its allocated MIM 09.04.2024 P192665PC00 fragment and will note that the fragment f7 of node N7 is missing. In order to ensure that all honest nodes receive the broadcast message m, the nodes N3, N4 and N5 send the missing fragment f7 to the receiver node N7. As can be seen from the example illustrated in FIGS. 3a-3e, even though the sender node N1 acts Byzantine, all the honest nodes N2-N6 eventually receive the broadcast message m. More particularly, it can be ensured that if one of the honest nodes receive the broadcast message m, also the other honest nodes will eventually receive it. FIG. 4a shows a flow chart comprising a main flow of steps of a method for broadcasting a message m in a distributed network, e.g. the network 100 of FIG. 1, according to an embodiment of the invention. FIG. 4b shows a more detailed flow chart with some sub-steps concerning an embodiment involving proposals which may be added to the main flow shown in FIG. 4a according to an embodiment of the invention. FIG. 4c shows a more detailed flow chart with some sub-steps involving threshold signatures which may be added to the main flow shown in FIG. 4a according to another embodiment of the invention. Referring at first to FIG. 4a, at a step 410 a sender node of the distributed network encodes the message m into n encoded fragments by a (n, n-t) erasure code. This step includes an allocation, by the sender node, of each fragment of the n encoded fragments to one corresponding node of the set of nodes including the sender node itself. Then, at a step 420, the respective sender node sends to each node of the set of n-1 receiver nodes its allocated fragment via a unicast message. MIM 09.04.2024 P192665PC00 Next, at a step 430, the set of nodes, i.e., the sender node as well as the receiver nodes, broadcast its respective allocated fragment to the set of receiver nodes. According to embodiments, the set of receiver nodes may also send their respective fragments to the sender node, but this is not necessary for the execution of the protocol. Once a respective node detects, at a checking step 440, that n-t fragments have been received for a message, the node reconstructs the message at a step 450. This step may include a verification of the reconstructed message. Next, at a step 460, the respective receiver node checks whether it has received from each of the other n-2 receiver nodes of the set of receiver nodes its allocated fragment. If there are one or more missing fragments from one or more of the other n-2 receiver nodes, the respective receiver node sends, at a step 470, by unicast messages the one or more missing fragments to the corresponding one or more receiver nodes from which no fragment has been received. Referring now to FIG. 4b, some additional steps are explained which may be performed in addition to the steps as illustrated in FIG. 4a, in particular between the steps 420 and 430 of FIG. 4a. At first, according to this embodiment the step 420 of transmitting the allocated fragments from the sender node to the receiver nodes comprises transmitting an execution identifier, a root hash and a Merkle proof with respect to the respective allocated fragment and the root hash. MIM 09.04.2024 P192665PC00 Then, the set of nodes perform at steps 421 and 422 a support protocol for collecting support messages for a respective root hash for a respective execution identifier. Such a support protocol is advantageous in terms of communication efficiency and may be embodied in various ways. In particular, it avoids the sending of fragments if the underlying message has not enough support. Accordingly, embodiments of the invention provide that the respective nodes only broadcast their allocated fragment once a predefined support criteria is met. In the embodiment of FIG. 4b the support protocol is implemented by means of proposals or in other words proposal messages. Accordingly, at a step 421 each node of the set of nodes broadcasts, upon receipt of its allocated fragment, a proposal comprising the execution identifier and the root hash of its allocated fragment. Before such a broadcast, the respective receiver node may verify the corresponding fragment by means of a verification of the Merkle proof for the root hash and the fragment. At a step 422, the node of the set of nodes checks whether a predefined number of corresponding or in other words matching proposals of the other nodes has been received for its allocated fragment or in other words for the hash of its allocated fragment. The predefined number may be in particular n-t. If this holds true, the support criteria has been met and the respective node broadcasts its allocated fragment, at a step 430, to the other nodes. According to embodiments, the nodes may perform, at a step 423, a further check, namely if they have received t+1 fragments for a respective root hash, but have not yet sent a corresponding proposal. If this MIM 09.04.2024 P192665PC00 holds true, the respective node broadcasts the proposal at a step 421. The t+1 received fragments indicate to the node that at least one node has received a sufficient number of proposals and hence supports the corresponding root hash of the message. Referring now to FIG. 4c, some additional steps are explained which may be performed in addition to the steps as illustrated in FIG. 4a, in particular between the steps 420 and 450 of FIG. 4a. The embodiment as illustrated in FIG. 4c may be in particular executed as an alternative to the method as illustrated in FIG. 4b. At first, also according to this embodiment, the step 420 of transmitting the allocated fragments from the sender node to the receiver nodes comprises transmitting an execution identifier, a root hash and a Merkle proof with respect to the respective allocated fragment and the root hash. Then, at a step 431, each of the nodes executes, upon receipt of its allocated fragment, a threshold signature on a tuple comprising the execution identifier and the root hash of the received fragment. As the sender node already has its allocated fragment, it may of course not wait until it is received. At a step 432, each of the nodes broadcasts the respective threshold-signed tuple as well as its allocated fragment. Furthermore, the nodes observe, at steps 440, whether they have received n-t signed tuples and corresponding fragments. Upon collection of n-t signed tuples for a root hash that the respective node has already supported (i.e., for which the respective node has broadcast, at step 432, MIM 09.04.2024 P192665PC00 a signed tuple and its individual allocated fragment), the respective node executes, at a step 441, a multi-signature on the tuple and broadcasts the tuple signed with the multi-signature. The multi-signature combines n-t threshold signatures into a compact signature. The multi- signature serves as a proof that the respective node that broadcasts it has received threshold signatures from n-t nodes. Then, the node may proceed with a step 450, namely with reconstructing and verifying the message. Furthermore, the nodes perform, at a step 442, a further check, namely if they have received (n-t) tuples for a root hash that they have not supported so far (i.e., for which the respective node has not broadcast, at step 432, a signed tuple and its own individual allocated fragment). If this holds true and in addition the own individual allocated fragment is available, the respective node broadcasts, at a step 443, its own individual allocated fragment. The steps 442 and 443 address e.g. a scenario in which the sender node has sent a faulty tuple with a wrong root hash to a receiver node. As soon as such a node has received (n-t) tuples for the correct hash, it can recognize the error and support the correct hash. Referring now to Fig. 5, a more detailed block diagram of a network node 10 according to embodiments of the invention is shown, e.g. of the network 100 of FIG. 1. The network node 10 establishes a computing node that may perform computing functions and may hence be generally embodied as a computing system or computer. The network node 10 may be e.g. a server computer. The network node 10 MIM 09.04.2024 P192665PC00 may be configured to perform or participate in a computer- implemented method for broadcasting a message in a distributed network as described above. The network node 10 may be operational with numerous other general purpose or special purpose computing system environments or configurations. The network node 10 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. The network node 10 is shown in the form of a general-purpose computing device. The components of network node 10 may include, but are not limited to, one or more processors or processing units 515, a system memory 520, and a bus 516 that couples various system components including system memory 520 to processor 515. Bus 516 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus. Network node 10 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by network node 10, and MIM 09.04.2024 P192665PC00 it includes both volatile and non-volatile media, removable and non-removable media. System memory 520 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 521 and / or cache memory 522. Network node 510 may further include other removable / non- removable, volatile / non-volatile computer system storage media. By way of example only, storage system 523 can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a "hard drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable, non- volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such instances, each can be connected to bus 516 by one or more data media interfaces. As will be further depicted and described below, memory 520 may include at least one computer program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention. Program / utility 530, having a set (at least one) of program modules 531, may be stored in memory 520 by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules 531 generally carry out the functions and / or methodologies of embodiments of the invention as described herein. Program modules 531 may carry out in MIM 09.04.2024 P192665PC00 particular one or more steps of a computer-implemented method for providing a user of a distributed network access to computational results computed by the distributed network, e.g. of one or more steps of the methods as described above. Network node 10 may also communicate with one or more external devices 517 such as a keyboard or a pointing device as well as a display 518. Such communication can occur via Input / Output (I / O) interfaces 519. Still yet, network node 10 can communicate with one or more networks 40 such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via network adapter 541. According to embodiments the network 540 may be in particular a distributed network comprising a plurality of network nodes 10, e.g. the network 100 as shown in FIG. 1. As depicted, network adapter 541 communicates with the other components of network node 10 via bus 516. It should be understood that although not shown, other hardware and / or software components could be used in conjunction with network node 10. Fig. 6 shows performance numbers when encoding / decoding a message of size 1MiB for various network sizes and two different parameterizations. The circles and bars mark the average and 5th / 95thpercentiles of the measured encoding and decoding times, respectively, over 1000 runs. The experiments were conducted on standard hardware using an optimized library for Reed-Solomon codes. The figure confirms the practicality of erasure coding, with encoding times in the sub-millisecond range, and scalability with respect to the number of nodes. Moreover, the figure reveals that the encoding(decoding)time is lower MIM 09.04.2024 P192665PC00 by a factor of 2.2-2.4 (1.8-2.0) for all network sizes when using an (n, n-t)-erasure code. Another interesting property is that the variance is also significantly lower, leading to more predictable encoding and decoding times. In the following further details of methods according to embodiments of the invention will be described. In particular, a first detailed embodiment will be described which encompasses two algorithms denoted as Algorithm 1 and Algorithm 2. The first detailed embodiment establishes a detailed description of an implementation of an embodiment which uses proposals as described above with reference to FIG. 4b and is denoted in the following as "proposal embodiment". A second detailed embodiment encompasses also two algorithms denoted as Algorithm 3 and Algorithm 4. The second detailed embodiment establishes a detailed description of an implementation of an embodiment which uses threshold signatures as described above with reference to FIG. 4c and is denoted in the following as "threshold signature embodiment". Generally, it is assumed in the following that each node has access to the routine get_fragments that takes a message ^ as input and returns a list of ^ fragments of size each. Moreover, the nodes use the routine recover_message to recover ^ given any subset ^ of the ^ fragments of size |^| ≥ ^ = 2^ + 1. In addition to fragments, the nodes also send hashes, identifiers, and, in the second embodiment, threshold signatures. The hashes are assumed to be cryptographically strong in the sense that it is infeasible to find hash collisions. Naturally, it is also assumed that signatures cannot be spoofed. Since the cryptographic properties only hold for hashes and signatures of a certain MIM 09.04.2024 P192665PC00 minimum size, we introduce a security parameter ^ anddefine that all data types other than fragments are of size^(^).For a specific number ^ of nodes, number ^ of Byzantine nodes, and message size ℓ, the communication complexity C(^,^, ℓ) of an algorithm is the total number of bits sent by all honest nodes in the worst case. Given that at least ^ℓ bits need to be transferred and addressing in particular the overhead for large messages, a goal is to minimize Additionally, the time complexity of an algorithm is of practical importance, measuring the duration of an execution when normalizing the maximum message delay to 1 time unit. According to the definition of reliable broadcast, an execution with a Byzantine sender may never terminate. Therefore, embodiments of the invention pay in particular attention to the good-case time complexity when the sender is honest. Due to the validity condition, the time complexity must be bounded in this case. Lastly, the space complexity may be considered as well, which is defined as the number of bits that each node stores during the execution of the algorithm in the worst case. As described above, according to methods of embodiments of the invention, an honest sender sends a valid fragment to each node (including itself) and then all honest nodes broadcast their fragments. Based on this assumption, each honest node will eventually receive at least 2^ +1 or in other words (n-t) fragments, which entails that all honest nodes can recover the message when using a (^, 2^ + 1)-erasure code. However, two-steps are not MIM 09.04.2024 P192665PC00 sufficient if the sender is faulty. Hence, according to embodiments an additional rule is introduced to ensure that the totality property holds: Before delivering ^, node ^ sends the ^^ℎfragment to node ^^if ^ did not receive any fragment from ^^. This step guarantees the eventual recovery of^ at all honest nodes if there is an honest node that delivers ^. Since each node broadcasts its fragment and then transmits ^ fragments in addition, the communication complexity is plus some quadratic term in ^ (independent of |^|). Embodiments of the invention use Merkle proofs to ensure the validity of fragments. According to the proposal embodiment, integrity is guaranteed by introducing a round of proposals endorsing a particular (Merkle) root hash. The proposal messages also serve to keep the communication complexity low. In short, the basic flow of the proposal embodiment is as follows. After the sender node disseminates the fragments, each node broadcasts the proposal for the corresponding root hash. Once sufficiently many proposals for the same root hash have been received and a matching fragment is available, the fragment is broadcast. Lastly, if a node receives (n-t) valid fragments and recovers ^, it performs the additional step of sending fragments to a subset of ^ nodes before delivering ^. Algorithm 1 encompasses triggered actions, while Algorithm 2 encompasses state-based actions: MIM 09.04.2024 P192665PC00 The algorithm according to the proposal embodiment is referred to as A^^^. It makes use of the routines get_fragments andrecover_message to generate fragments of a given message and recover the message given at least (n-t) valid fragments, respectively. Furthermore, it comprises routines for Merkle tree operations, specifically,get_merkle_root yields the Merkle root hash for a given set MIM 09.04.2024 P192665PC00 of fragments, get_merkle_proof returns the Merkle proof for a specific fragment, and valid_merkle_proof indicates whether a given Merkle proof is correct. Each node executing algorithm A^^^ locally maintains the data structures ^^^ , ^^^ , ^^^ , and ^^^ for a specific execution context with identifier ^^. Let F , Π, and H denote the set of all possible fragments, Merkle proofs, and hashes, respectively. The hash map ^^^: H ×^ → F ×Π stores the fragment ^^∈ F and Merkle proof ^^ ∈ Π of node ^^ for the message with the root hash ℎ ∈ H. If this fragment is locally available, then ^^^ (ℎ,^^) = (^^,^^), and ^^^ (ℎ,^^) = ⊥ otherwise. This hash map is used to collect fragments with the goal of eventually recovering the corresponding message. The hash map ^^^ : H → 2^stores the nodes from which a fragment for the root hash ℎ has been obtained. This hash map is needed to determine which nodes may still be missing their fragments once a node is able to recover the message. Conversely, for any node ^, the hash map ^^^ : ^ → 2Hcontains the set of hashes for which a proposal or fragment was received from ^. The purpose of this data structure is to bound both the communication and space complexity. Lastly, ^^^ : H → 2^indicates which nodes have proposed the delivery of the message associated with the Merkle root hash ℎ. The collected proposals are used to ensure that the integrity property holds and also serve to bound the number of exchanged fragments. All hash maps are initially empty. In addition to the hashmaps, each node further uses the boolean variable ^^^^^^, initially ^^^^^, to capture the information whether the execution has terminated, either with or without the delivery of a message. For the latter case, the totality condition implies that no honest node will deliver a message for identifier ^^. Let further ^^^ ≔ ∪^∈^ ^^^ (^) and ℎ^^^ ≔ arg maxℎ∈^^^ |^^^ (ℎ)|, breaking ties arbitrarily if there is no single hash for which the most proposals have been received. The algorithm distinguishes between <triggered actions=, which are executed when a function is invoked or a message is received, and <state-based actions=, which occur when some conditions hold for the local state. This separation facilitates the description and analysis of the algorithm’s properties. Algorithm A^^^ is formally stated with respect to its triggered actions in Algorithm 1 and its state-based actions in Algorithm 2. The triggered actions are discussed first. Given an identifier ^^ and a message ^, a reliable broadcast is triggered by invoking the routine reliable_broadcast at some node ^^, which performs the steps of generating ^ fragments ^1,. . . , ^^, computing the Merkle root hash ℎ, and then transmitting^^^^^^^^ (^^, ℎ, ^, ^^, ^^), which contains the corresponding Merkle proof ^^ , to ^^ for all ^ ∈ {1, . . .,^}. A node ^^ only accepts a received message ^^^^^^^^ (^^, ℎ, ^, ^^, ^^ ) from some node ^^ under the following conditions. First, the sender ^^ must have sent the fragment of the recipient ^^ (i.e., ^ = ^) or its own fragment (i.e., ^ = ^). Second, the sender has not sent messages for two Merkle root hashes other than ℎ before (formally, |^^^ (^^)| < 2 or ℎ ∈ ^^^ (^^)) and, lastly, the Merkle proof ^^ in the received message is valid. If all conditions are met, the hash maps ^^^ and^^^ are updated by adding ℎ and ^^, respectively, and the fragment and Merkle proof are stored (^^^ (ℎ, ^^) ≔ (^^,^^ )). In the final MIM 09.04.2024 P192665PC00 step, if the receiver node received its fragment (i.e., ^ = ^) and it is the first fragment received from the dedicated sender node (i.e., ^^ = ^^^^^^^^), then ^^ broadcasts ^^^^^^^^ (^^, ℎ). Whenever a proposal of the form ^^^^^^^^ (^^, ℎ) is received from node ^^, it is again only accepted if ^^ did not send messages associated with two other hashes before, in which case ℎ is added to ^^^ (^^) and ^^ is added to ^^^ (^^). In the following the state-based actions of Algorithm 2 are discussed. As mentioned earlier, an honest node ^^ only broadcasts its fragment after collecting sufficiently many proposals for the corresponding Merkle root hash ℎ, specifically (n-t) proposals, and only broadcasts it once. A node ^^ can still broadcast a proposal for a specific root hash ℎ even if it never receives its fragment from s^^^^^^^. As shown in the second paragraph, if ^^ receives at least t + 1 fragments for the root hash ℎmax withthe most proposals, ^^ broadcasts ^^^^^^^^ (^^,ℎmax) unless it has broadcast this message before.Lastly, if a node ^^ receives at least (n-t) fragments and proposals for ℎmax it recovers the messagem, recomputes the fragments and the corresponding root hash. If the computed hash matches ℎmax,node ^^ concludes that the fragments are valid and the message m can be delivered. In this case, ^^first recomputes the Merkle proof ^^ and sends ^^^^^^^^ (^^, ℎ, ^, ^^, ^^ ) to each ^j ∈ V ^^^ (ℎmax)before calling deliver(ID, m) to deliver the message. According to the embodiment doneID is set totrue after executing these steps even if ℎ ≠ ℎmax because it is computationally infeasible forByzantine nodes to find fragments such that equality holds for some subsets of fragments of size(n-t).The algorithm Abit reduces the overhead factor to 2 and has a time complexity of 3 if the sender ishonest.In the following, the algorithm according to the threshold signature embodiment is described in more detail called A^^^, with an optimal time complexity of 2 while still guaranteeing that L(^,^) < 3. The challenge is that this time complexity cannot be reached when sending proposals to agree on a root hash first before sending fragments. However, if fragments are broadcast right away, a Byzantine sender can cause havoc by sending fragments for different root hashes to different nodes. Naturally, honest nodes cannot simply broadcast any received fragments without an adverse effect on thecommunication complexity.MIM 09.04.2024 P192665PC00 Algorithm A^^^addresses this challenge by using threshold signatures. For this embodiment it is assumed that each node has the keying material to threshold-sign any message and that every node can verify the validity of signatures of all nodes. Additionally, it is assumed that (n-t) threshold signatures can be combined into a multi-signature that is compact in the sense that its size is also bounded by ^(^). The embodied algorithm A^^^ differs from A^^^ in that it utilizes threshold-signature in place of proposals. An advantage is that such a multi-signature may serve as proof that the sender has received threshold signatures from (n-t) nodes, ensuring that the execution can make progress whenever a multi-signature has been compiled. More particularly, when a node receives a fragment MIM 09.04.2024 P192665PC00 with root hash ℎ from ^^^^^^^^, it broadcasts the signed tuple (^^, ℎ) and its fragment. As soon as a node has collected at least (n-t) signatures and fragments, it computes and broadcasts the multi- signature before executing the same delivery steps as in Algorithm 2. Algorithm A^^^ uses according to embodiments a message of the form ^^^^^^^^^(^^,ℎ,^), where ^ is either the threshold signature of (^^,ℎ) of a particular node or it is a compact multi-signature of (^^,ℎ) comprising at least (n-t) threshold signatures. As mentioned above, the size of threshold signatures and multi-signatures is bounded by ^(^). The algorithm also uses the hash maps ^^^, ^^^ , and ^^^. Threshold signatures may be collected in a hash map ^^^ : H × ^ → S, where S denotes the set of all possible signatures. It may be further defined that ^^^ (ℎ) ≔ ∪^∈^ ^^^ (ℎ,^) and ℎ^^^ ≔ arg maxℎ∈H |^^^ (ℎ)|. In addition to ^^^^^^, each node further stores ℎ^^, the root hash of the message that will be delivered if set (initially, ℎ^^ = ⊥). The steps of algorithm A^^^ for triggered actions are shown in Algorithm 3. When reliable broadcast is invoked with parameters ^^ and ^, exactly the same steps as in Algorithm 1 are executed. A message ^^^^^^^^(^^,ℎ, ^, ^^,^^ ) may be handled the same way as in A^^^ with the exception that (^^,ℎ) is signed and both ^^^^^^^^^(^^,ℎ,^^) and ^^^^^^^^(^^,ℎ, ^^,^,^^) are broadcast if it is the first (valid) fragment received from ^^^^^^^^. When receiving ^^^^^^^^^(^^, ℎ, ^) from some node ^^, the action depends on ^. If it is a valid multi-signature, ℎ^^is set to ℎ. Otherwise, if it is a valid threshold signature instead and ^^^(^^) does not contain two hashes different from ℎ, then ℎ is added to ^^^ (^^) and ^^^ (ℎ,^^ is set to ^. The state-based actions at node ^^ are shown in Algorithm 4. If at least (n-t) threshold signatures have been collected for some root hash ℎ^^^, then ℎ^^is set to ℎ^^^. Only one such multi-signature can be created for a particular execution context, therefore it may be guaranteed that honest nodes will not set ℎ^^ to different hashes. If ℎ^^ is set, node ^^ broadcasts its fragment ^^ (with the Merkle proof ^) if the fragment is locally available and has not been broadcast before. Lastly, if ℎ^^ ≠ ⊥ and |^^^ (ℎ^^ )| ≥ n-t, node ^^ computes and broadcasts the multi-signature beforeexecuting the same delivery steps as in Algorithm 2.As mentioned above, instead of handling fragments and signatures in separate messages, thesignatures and the fragments may be combined. More particularly, the signature may beappended to the fragment message. According to such an embodiment, the nodes only send andprocess messages of a single type.Byzantine behavior and unpredictable message latencies are often exceptional situations ratherthan the norm in practice. The above-described algorithms Abit and A^^^ are in particular tailoredto the asynchronous communication model, but according to embodiments they may be alsoadapted to a partially synchronous model where periods of synchrony are assumed.As an example, given an upper bound ^ on the message delay that holds for some periods oftime, both algorithms may be modified to improve the communication complexity during theseMIM 09.04.2024 P192665PC00times in the absence of faults. According to such an embodiment, a node may wait for apredetermined time interval to receive more than (n-t) fragments. This may avoid sendingfragments unnecessarily.According to another embodiment the Merkle proofs for the root hash and the correspondingfragment may be replaced by standard signatures for the fragments received from ^^^^^^^^.According to such an embodiment, Merkle proofs are only used when sending fragments forwhich ^^^^^^^^’s signature is not available. Such an embodiment necessitates the ability toverify signatures from all other nodes, which is a requirement for algorithm A^^^ anyway. Inalgorithm A^^^ and A^^^, the signature is only missing when sending fragments as part of the stepsto deliver the message. Hence no Merkle proofs are required in the benign case where messagesare delivered within bounded time and there are no faults, reducing the term ^(^^2 log(^)) to^(^^2), which is nearly optimal in light of the Ω(^2) lower bound. However, according to suchan embodiment, an additional rule is provided: If a node receives a fragment with a valid Merkleproof, this fragment is stored, potentially overriding another fragment that was received with^^^^^^^^’s signature. Moreover, the fragment with the Merkle proof is then broadcast if theoverridden fragment has been broadcast before. If there is an honest node that delivers ^, thisrule ensures that all honest nodes eventually broadcast correct fragments of ^. Thisembodiment comes at the expense of increased computational complexity.The algorithm A^^^ attains an optimal time complexity of 2 and an overhead factor of 2 in theabsence of equivocation. If the Byzantine sender equivocates, the worst-case overhead factor is5 / 2.In the following, an exemplary proof of the correctness of Abit is provided:A series of lemmas is used to simplify the proof structure. The first lemma is concerned with thefragments that honest nodes broadcast, showing that the proposal mechanism successfullyensures that honest nodes only broadcast fragments for one specific root hash.Lemma 3.1. If honest nodes ^ and ^′ broadcast fragments for root hashes ℎ and ℎ′, then ℎ = ℎ′.Proof. Without loss of generality, let ℎ be the first hash for which n-t proposals are received atsome node ^. Thus, there are at least ^ + 1 honest nodes that received their fragments from^^^^^^^^ and then broadcast their first proposal for root hash ℎ.Let ^ ′ be the first node that broadcasts a fragment for a hash ℎ′ ≠ ℎ. Since it must hold that|^^^ (ℎ′)| ≥ n-t at node ^ ′, there must be at least ^ + 1 honest nodes that broadcast the proposalfor root hash ℎ′. Consequently, there must be an honest node ^∗ that first proposed ℎ and then ℎ′.However, ^∗ only sends a proposal for ℎ′ if |^^^ (ℎ′)| ≥ ^ + 1 according to Algorithm 2, whichMIM 09.04.2024 P192665PC00implies that it must have received a fragment for root hash ℎ′ from an honest node before. Thisis a contradiction to the assumption that ^ ′ is the first node that broadcasts such a fragment.Since algorithm A^^^ imposes restrictive rules for the acceptance of received messages, we mustshow that honest nodes always accept messages from other honest nodes regardless of themessages of Byzantine nodes.Lemma 3.2. If an honest node ^ sends a proposal or fragment message to an honest node ^ ′,then ^ ′ stores it.Proof. According to Algorithm 1, ^ ′ stores messages associated with at most two differenthashes for any sender ^.After an initial proposal for some root hash ℎ, ^ may send a second proposal for ℎ′ if |^^^ (ℎ′)|>= ^ + 1, i.e., there is at least one honest node that has broadcast a fragment for root hash ℎ′.Assume that ^ sends another proposal for a different root hash ℎ′′, which again implies that atleast one honest node must have broadcast a fragment for this root hash. Having honest nodessend fragments for different root hashes is a contradiction to Lemma 3.1.Regarding the transmission of fragments, Lemma 3.1 also implies that an honest node onlysends fragments for one root hash. Assume that ^ sends fragments for a root hash ℎ′′ that differsfrom the hashes ℎ and ℎ′ for which it sent proposals. In this case, ^ must have received at least ^+ 1 fragments for one of the root hashes ℎ or ℎ′. Hence it follows that an honest node broadcastsa fragment for a root hash other than ℎ′′, again contradicting Lemma 3.1.A criterion for the totality property is that all honest nodes eventually manage to get sufficientlymany fragments of a message ^ if there is an honest node that delivers ^. The last lemma statesthat this is indeed the case for algorithm A^^^.Lemma 3.3. If an honest node ^ delivers ^, all honest nodes will eventually receive at least n-tfragments of ^.Proof. Assume that ^ delivers ^ with root hash ℎ. Since |^^^ (ℎ)| ≥ n-t, ^ received fragments of^ from at least ^ + 1 honest nodes, i.e., every honest node eventually receives at least ^ + 1fragments of ^. As a result, every honest node eventually broadcasts ^^^^^^^^ (^^, ℎ) and thus|^^^ (ℎ)| ≥ 2^ + 1 eventually holds at all honest nodes.Node ^ adds all nodes from which it received fragments for root hash ℎ to the set ^^^ (ℎ). Forany node ^ ′ ∈ ^^^ (ℎ) it holds that ^ ′ either sent its own fragment ^ ′ or ^’s fragment. However,the latter case also implies that ^ ′ must have its own fragment. According to Algorithm 1, ^sends fragment ^^ to ^^ for all ^^ ∈ ^ \^^^ (ℎ), guaranteeing that the remaining nodes eventuallyreceive and, due to Lemma 3.2, store their fragments as well. Thus, it eventually holds that |^^^(ℎ)| ≥ n-t and ^^^ (^^, ℎ) ≠ ⊥ at all honest nodes, causing them to broadcast their fragments.MIM 09.04.2024 P192665PC00Consequently, every honest node will eventually receive fragments of ^ from at least n-t honestnodes. We are now in the position to prove the following main result.Theorem 3.4. Algorithm A^^^ implements reliable broadcast in the asynchronous communicationmodel with ^ < ^ / 3 Byzantine nodes.Proof. The four conditions of reliable broadcast are proved separately.Validity: If the sender ^ of a message ^ with root hash ℎ is honest, it sends the fragment ^^ to ^^for all ^^ ∈ ^. Subsequently, every honest node broadcasts ^^^^^^^^ (^^, ℎ). Since all honestnodes eventually receive at least n-t proposals for hash ℎ (and only for hash ℎ), they allbroadcast their fragments. Thus, eventually ^^^ (ℎ)| ≥ n-t and |^^^ (ℎ)| ≥ n-t holds at all honestnodes, triggering the delivery of ^.Agreement: Assume for the sake of contradiction that honest nodes ^ and ^ ′ deliver distinctmessages ^ and ^′ with root hashes ℎ and ℎ′, respectively. Since |^^^ (ℎ)| ≥ n-t at ^ and |^^^(ℎ′)| ≥ n-t at ^ ′, there must be honest nodes that have broadcast fragments for ℎ and ℎ′, whichcontradicts Lemma 3.1.Integrity: Lemma 3.1 implies that there can only be sufficiently many fragments for at most onehash and hence at most one message can be delivered.Totality: Let ^ be a node that delivers a message ^ with root hash ℎ. Due to Lemma 3.3, it holdseventually that honest nodes receive at least n-t fragments of ^. Since |^^^ (ℎ′)| ≥ n-t at node ^,there are at least ^ + 1 honest nodes that broadcast their fragments. As a result, all honest nodeswill eventually receive at least ^ + 1 fragments and propose ℎ. Thus, |^^^ (ℎ)| ≥ n-t also holds atevery honest node eventually, causing all honest nodes to deliver ^.Aspects of the present invention may be embodied as a system, in particular a distributednetwork, a method, and / or a computer program product. The computer program product mayinclude a computer readable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of the present invention.Computer readable program instructions described herein can be downloaded to respectivecomputing / processing devices from a computer readable storage medium or to an externalcomputer or external storage device via a network, for example, the Internet, a local areanetwork, a wide area network and / or a wireless network. A network adapter card or networkinterface in each computing / processing device receives computer readable programinstructions from the network and forwards the computer readable program instructions forstorage in a computer readable storage medium within the respective computing / processingdevice.MIM 09.04.2024 P192665PC00Computer readable program instructions for carrying out operations of the present inventionmay be assembler instructions, instruction-set-architecture (ISA) instructions, machineinstructions, machine dependent instructions, microcode, firmware instructions, state-settingdata, or either source code or object code written in any combination of one or moreprogramming languages, including an object oriented programming language such as Smalltalk,C++ or the like, and conventional procedural programming languages, such as the "C"programming language or similar programming languages.Aspects of the present invention are described herein with reference to flowchart illustrationsand / or block diagrams of methods, networks, apparatus (systems), and computer programproducts according to embodiments of the invention.Computer readable program instructions according to embodiments of the invention may beprovided to a processor of a general purpose computer, special purpose computer, or otherprogrammable data processing apparatus to produce a machine, such that the instructions,which execute via the processor of the computer or other programmable data processingapparatus, create means for implementing the functions / acts specified in the flowchart and / orblock diagram block or blocks. These computer readable program instructions may also bestored in a computer readable storage medium that can direct a computer, a programmable dataprocessing apparatus, and / or other devices to function in a particular manner, such that thecomputer readable storage medium having instructions stored therein comprises an article ofmanufacture including instructions which implement aspects of the function / act specified in theflowchart and / or block diagram block or blocks.The computer readable program instructions may also be loaded onto a computer, otherprogrammable data processing apparatus, or other device to cause a series of operational stepsto be performed on the computer, other programmable apparatus or other device to produce acomputer implemented process, such that the instructions which execute on the computer, otherprogrammable apparatus, or other device implement the functions / acts specified in theflowchart and / or block diagram block or blocks.The flowchart and block diagrams in the figures illustrate the architecture, functionality, andoperation of possible implementations of networks, systems, methods, and computer programproducts according to various embodiments of the present invention. In this regard, each blockin the flowchart or block diagrams may represent a module, segment, or portion of instructions,which comprises one or more executable instructions for implementing the specified logicalfunction(s). In some alternative implementations, the functions noted in the block may occur outof the order noted in the figures. For example, two blocks shown in succession may, in fact, beexecuted substantially concurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved.MIM 09.04.2024 P192665PC00While there are shown and described presently preferred embodiments of the invention, it is tobe distinctly understood that the invention is not limited thereto but may be otherwise variouslyembodied and practiced within the scope of the following claims.MIM 09.04.2024 P192665PC00

Claims

Claims 1. A method for broadcasting a message in a distributed network, the distributed network comprising a set of n nodes, wherein for a respective broadcast the set of nodes is split into a sender node and set of n-1 receiver nodes, wherein at most t nodes of the set of nodes are Byzantine nodes, wherein t and n are integers and t < (n / 3), the method comprising encoding the message, by the sender node, into n encoded fragments by a (n, n-t) erasure code; allocating, by the sender node, each fragment of the n encoded fragments to one corresponding node of the set of nodes including the sender node itself; transmitting, by the sender node, to each node of the set of n-1 receiver nodes its respective allocated fragment; broadcasting, by each node of the set of nodes, its respective allocated fragment to the set of receiver nodes; reconstructing, by the respective receiver node, upon receipt of (n-t) fragments, the message; checking, by each of the receiver nodes, whether it has received from each of the other n-2 receiver nodes of the set of receiver nodes its allocated fragment; and if there are one or more missing fragments from one or more of the other n-2 receiver nodes, transmitting, by the respective receiver node, the one or more missing fragments to the corresponding one or more receiver nodes from which their respective allocated fragment has not been received. MIM 09.04.2024 P192665PC002. A method according to claim 1, further comprising providing an authenticated communication channel for the communication between the set of nodes.

3. A method according to claim 1 or claim 2, further comprising waiting for a predetermined time interval before sending the missing fragments.

4. A method according to any of the preceding claims, wherein the erasure code is an erasure code with optimal reception efficiency.

5. A method according to claim 4, wherein the erasure code is selected from the group consisting of: a Reed–Solomon code; and an Erasure Resilient Systematic Code.

6. A method according to any of the preceding claims, wherein the transmitting of its allocated fragment comprises transmitting an execution identifier, a root hash and a Merkle proof with respect to its allocated fragment and the root hash.

7. A method according to claim 5 or claim 6, further comprising verifying, after reconstructing the message, whether the received (n-t) fragments are consistent with the root hash of the reconstructed message. MIM 09.04.2024 P192665PC008. A method according to any of the preceding claims 5-7, further comprising performing the method in parallel for a plurality of messages having different execution identifiers.

9. A method according to any of the preceding claims 5-8, further comprising performing, by each of the receiver nodes, upon receipt of a fragment from the sender node or any of the other n-2 receiver nodes, a verification of the received fragment by means of the root hash and the Merkle proof; and storing a received fragment upon successful verification.

10. A method according to any of the preceding claims 5-9, further comprising performing, by the set of nodes, a support protocol for collecting support messages for a respective root hash for a respective execution identifier; and performing, by each node of the set of nodes, the step of broadcasting its allocated fragment once a predefined support criteria has been met for the root hash of the execution identifier.

11. A method according to any of the preceding claims 5-10, further comprising broadcasting, by each of the nodes, a proposal comprising the execution identifier and the root hash of its allocated fragment; and performing, by each node of the set of nodes, the step of broadcasting its allocated fragment once a predefined number of corresponding proposals of the other nodes have been received for its allocated fragment. MIM 09.04.2024 P192665PC0012. A method according to any of the preceding claims 5-11, further comprising broadcasting, by each of the receiver nodes, upon receipt of t+1 fragments for a respective root hash, a proposal comprising the execution identifier and the root hash of the t +1 received fragments if the corresponding proposal has not been sent before.

13. A method according to any of the preceding claims 5-9, further comprising executing, by each of the nodes, upon receipt of its allocated fragment, a threshold signature on a tuple comprising the execution identifier and the root hash of its allocated fragment; and broadcasting, by each of the nodes, the respective threshold-signed tuple.

14. A method according to claim 13, further comprising broadcasting the threshold-signed tuple together with its corresponding fragment.

15. A method according to claim 13 or 14, further comprising executing, by a node, upon collection of n-t signed tuples, a multi-signature on the tuple; and broadcasting the tuple signed with the multi- signature.

16. A method according to any of the preceding claims 13-15, further comprising performing, by each of the receiver nodes, a check if it has received (n-t) tuples for a root hash for MIM 09.04.2024 P192665PC00which it has not yet broadcast a signed tuple and its own individual allocated fragment; and if this holds true and its own individual allocated fragment is available, broadcasting, by the respective receiver node, its own individual allocated fragment.

17. A distributed network comprising a set of n nodes, wherein at most t nodes of the set of nodes are Byzantine nodes, wherein t and n are integers and t < (n / 3), wherein the distributed network is configured to perform a method for broadcasting a message from a sender node to a set of n-1 receiver nodes, the method comprising encoding the message, by the sender node, into n encoded fragments by a (n, n-t) erasure code; allocating, by the sender node, each fragment of the n encoded fragments to one corresponding node of the set of nodes including the sender node itself; transmitting, by the sender node, to each node of the set of n-1 receiver nodes its allocated fragment; broadcasting, by each node of the set of nodes, its allocated fragment to the set of receiver nodes; reconstructing, by the respective receiver node, upon receipt of (n-t) fragments, the message; checking, by each of the receiver nodes, whether it has received from each of the other n-2 receiver nodes of the set of receiver nodes its allocated fragment; and if there are one or more missing fragments from one or more of the other n-2 receiver nodes, sending, by the respective receiver node, the one or more missing fragments to the corresponding one or MIM 09.04.2024 P192665PC00more receiver nodes from which their respective allocated fragment has not been received.

18. A computer program product for operating a distributed network comprising a set of n nodes, wherein at most t nodes of the set of nodes are Byzantine nodes, wherein t and n are integers and t < (n / 3), wherein the distributed network is configured to perform a method for broadcasting a message from a sender node to a set of n-1 receiver nodes, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by the set of nodes to cause the set of nodes to perform a method comprising encoding the message, by the sender node, into n encoded fragments by a (n, n-t) erasure code; allocating, by the sender node, each fragment of the n encoded fragments to one corresponding node of the set of nodes including the sender node itself; transmitting, by the sender node, to each node of the set of n-1 receiver nodes its allocated fragment; broadcasting, by each node of the set of nodes, its allocated fragment to the set of receiver nodes; reconstructing, by the respective receiver node, upon receipt of (n-t) fragments, the message; checking, by each of the receiver nodes, whether it has received from each of the other n-2 receiver nodes of the set of receiver nodes its allocated fragment; and if there are one or more missing fragments from one or more of the other n-2 receiver nodes, sending, by the respective receiver node, the one or more missing fragments to the corresponding one or MIM 09.04.2024 P192665PC00more receiver nodes from which their respective allocated fragment has not been received.

19. A node for a distributed network according to claim 17, the node being configured to act as a sender node and to perform the steps of: encoding a message into n encoded fragments by a (n, n-t) erasure code; allocating each fragment of the n encoded fragments to one corresponding node of the set of nodes including itself; transmitting to each node of the set of n-1 receiver nodes its respective allocated fragment; broadcasting its own allocated fragment to the set of receiver nodes.

20. A node for a distributed network according to claim 17, the node being configured to act as a receiver node and to perform the steps of: receiving its allocated fragment from the sender node; broadcasting its allocated fragment to the set of receiver nodes; reconstructing, upon receipt of (n-t) fragments, the message; checking whether it has received from each of the other n-2 receiver nodes of the set of receiver nodes its allocated fragment; and if there are one or more missing fragments from one or more of the other n-2 receiver nodes, transmitting the one or more missing fragments to the corresponding one or more receiver nodes from which their respective allocated fragment has not been received. MIM 09.04.2024 P192665PC00

Images