METHOD AND SYSTEM FOR EXECUTING A BYZANTINE FAULT TOLERANT OR BFT PROTOCOL

Abstract

Method for executing a Byzantine Fault Tolerant or BFT protocol among a number of participating nodes (2) of a network (1), wherein the method comprises the following: Receiving a transaction request by a primary node (3) of the BFT protocol, The primary node (3) applies a data distribution protocol to distribute the transaction request among the participating nodes (2) via a data layer of the network (1), and Generating a hash of the transaction request by the primary node (3) and requesting consensus among the participating nodes (2) via a control plane of the network (1) using the hash of the transaction request, wherein the data processing protocol includes a resilience improvement mechanism, wherein the mechanism includes broadcasting Inv messages announcing the availability of a node (2) in the network (1) to serve the transaction request, wherein a node (2) starts a timer in response to receiving an Inv message and, if the transaction request corresponding to the Inv message has still not been received by the normal data processing protocol when this timer expires, the node (2) requests the transaction request from a node (2) that has broadcast an Inv message.

Description

[0001] The present invention relates to methods and systems for executing a BFT (Byzantine Fault Tolerant) protocol among a number of participating nodes of a network.

[0002] Byzantine Fault Tolerance (BFT) protocols are a family of protocols that attempt to achieve consensus among multiple participants who do not trust each other, even in the presence of adversaries. BFT protocols typically achieve provable properties as long as the number of adversaries does not exceed a certain threshold; for example, for N participants, up to f participants can be adversaries, with N ≥ 3. * f + 1.

[0003] Byzantine Fault Tolerance (BFT) protocols have recently emerged for use in conjunction with blockchain technology. However, BFTs are known for their poor performance in terms of throughput and latency, as well as their lack of scalability. In fact, most existing BFT protocols require a number of messages that is quadratically proportional to the number of participating nodes. Such protocols, such as Practical Byzantine Fault Tolerance (PBFTs), can only achieve agreement up to a few hundred kilobytes of data per second when using a quorum of approximately 10 nodes, resulting in a throughput of only a few hundred transactions per second, assuming a transaction size similar to that of blockchain protocols like Bitcoin.

[0004] From US patent 6,671,821 B1, a method for the fault-tolerant operation of a distributed server system comprising N asynchronous servers that may experience errors is known, comprising the following steps: receiving a series of requests from a client over a time interval associated with the requests; processing some or all of the client requests on each of the N servers, including, for each request processed on a server, updating the state of a state machine on that server in accordance with the request and sending a response to the client; and repeatedly resetting each of the N servers during the time interval, wherein resetting a server includes setting the state of the state machine on that server using data stored on other servers, such that the state on that server corresponds to a common state of the server system;wherein if (a) for a predetermined time window, less than N / 3 of the server systems have errors in any time window of the time interval of requests of that predetermined duration, and (b) N / 3 or more of the N servers have errors at any given time during the time interval of requests, the N servers provide responses to the client sufficient for the client to determine correct responses to each of the sets of requests.

[0005] Furthermore, Kotla, RR et al (Zyzzyva: Speculative Byzantine fault tolerance, In: ACM Transactions on Computer Systems (TOCS), Vol. 27, 2009, No. 4. DOI: 10.1145 / 1658357.1658358), Aublin, PL et al (The Next 700 BFT Protocols, In: ACM Transactions on Computer Systems (TOCS), Vol. 32, 2015, No. 4. DOI: 10.1145 / 2658994) and US 2019 / 0251077 A1 reveal improved and more efficient BFT protocols.

[0006] Cain, B. et al (Internet Group Management Protocol, Version 3. Request for Comments 3376, Network Working Group, October 2002. URL: https: / / www.rfc-editor.org / rfc / pdfrfc / rfc3376.txt.pdf) describes Internet protocols in general,

[0007] One object of the present invention is therefore to improve and further develop a method and a system for executing a BFT (Byzantine Fault Tolerance) protocol in such a way that the performance with regard to throughput and / or latency is improved.

[0008] According to the invention, the aforementioned problem is solved by a method for executing a Byzantine Fault Tolerant (BFT) protocol among a number of participating nodes of a network, the method comprising: receiving a transaction request by a primary node of the BFT protocol, distributing the transaction request among the participating nodes by the primary node via a data plane of the network using a data propagation protocol, generating a hash of the transaction request, and requesting consensus among the participating nodes by the primary node via a control plane of the network using the hash of the transaction request, wherein the data processing protocol includes a resilience enhancement mechanism, the mechanism comprising broadcasting Inv messages announcing the availability of a node in the network to serve the transaction request.where, in response to receiving an Inv message, a node starts a timer and, if the transaction request corresponding to the Inv message has still not been received through the normal data processing protocol when this timer expires, the node requests the transaction request from a node that has forwarded an Inv message.

[0009] Furthermore, the aforementioned task is solved by a system for executing a Byzantine Fault Tolerant (BFT) protocol in a network, wherein the system comprises a number of nodes participating in the BFT protocol, the number of participating nodes including a primary node of the BFT protocol designed to receive a transaction request, distribute the transaction request among the participating nodes via a data plane of the network using a data propagation protocol, generate a hash of the transaction request, and request consensus among the participating nodes via a control plane of the network using only the hash of the transaction request, wherein the data processing protocol includes a resilience improvement mechanism, the mechanism comprising broadcasting Inv messages announcing the availability of a node in the network to serve the transaction request.where, in response to receiving an Inv message, a node starts a timer and, if the transaction request corresponding to the Inv message has still not been received through the normal data processing protocol when this timer expires, the node requests the transaction request from a node that has forwarded an Inv message.

[0010] According to the invention, it was recognized that performance improvements of the BFT protocol can be achieved by reducing the message size of the BFT algorithm. Furthermore, it was recognized that a reduction in the message size of the BFT algorithm can be effectively achieved by decoupling the control plane (the actual consensus layer) from the data plane (the transactions). Consequently, embodiments of the present invention introduce a general optimization into BFT algorithms by decoupling the data from the actual protocol, thereby improving the BFT protocol performance and scalability. In particular, by combining the proposed decoupling with the use of FNF (Fastest Node First) as the data propagation protocol in the data plane, a very low-latency (and scalable) BFT algorithm can be achieved.

[0011] According to embodiments of the invention, the data of a transaction request is shared using a certain optimized data distribution algorithm, whereas the BFT algorithm would only perform consensus on the hash of the data, effectively reducing the message size of the consensus algorithm. As long as all the different nodes participating in the consensus algorithm receive the data from the data plane, the control plane can reach consensus on this data. The control plane does not need to provide any form of guarantee, since best-effort broadcasting is sufficient, and can therefore use simpler protocols, such as gossip protocols or data distribution protocols, to optimize throughput. Hereinafter, the terms "gossip protocols" and "data distribution protocols" are used synonymously.

[0012] According to embodiments, after distributing the data of a transaction request across the network's data plane and distributing a consensus request based on the transaction request's hash across the network's control plane, the primary node can resume the remaining steps of the consensus protocol as standard consensus operations. Specifically, the primary node can collect consensus responses from the participating nodes, indicating whether or not they agree with the respective transaction request. The primary node can terminate a consensus request when a predefined quorum of participating nodes has declared their agreement with the transaction request.

[0013] According to certain embodiments, a participating node can calculate a hash of the transaction request data upon receiving it via the network's data plane. Hashes calculated in this way can then be stored by the participating node, for example, in an internal database. Furthermore, when a participating node receives a consensus request based on a hash of a transaction request via the network's control plane, it can compare this hash with the (previously calculated and stored) hashes, for example, by scanning its internal database. This allows the participating node to efficiently identify the corresponding transaction request to which the consensus request refers.With regard to improving the reliability and trustworthiness of the protocol, it can additionally be provided that once a participating node has identified a transaction request belonging to a specific consensus request received from a primary node by comparing the respective hashes as described above, it sends an acknowledgment notification to the respective primary node.

[0014] According to embodiments of the invention, the method can be performed as follows: Upon startup of the BFT protocol (with the integrated optimization for separating the data plane from the control plane in the BFT network), network statistics and an optimization configuration of the data propagation layer can be provided. For this purpose, a topology component implemented in the data plane can be used, which, based on the network statistics and the optimization configuration, selects the best protocol to use for data propagation along with the operating parameters of the selected protocol. Once a participating node, acting as the primary node of the BFT protocol, receives a transaction request, the primary node sends the request through the data plane layer (using the selected data propagation protocol), while requesting consensus only using the hash of the transaction request.The peers of the BFT protocol receive the consensus request and wait for the data layer to receive the transaction request (i.e., the data) before responding. As with traditional BFT protocols, the primary device terminates the consensus request once enough nodes have agreed to it.

[0015] There are several ways in which the teaching of the present invention can be advantageously designed and further developed. For this purpose, one should refer, on the one hand, to the dependent claims and, on the other hand, to the following explanation of preferred embodiments of the invention with reference to examples illustrated by the figure. In conjunction with the explanation of the preferred embodiments of the invention with the aid of the figure, generally preferred embodiments and further developments of the teaching are explained. The figures show: Fig. 1 a schematic representation of a topology of a system with a BFT protocol according to an embodiment of the present invention and Fig. 2 a schematic representation of a transaction flow when using FNF for the data plane according to an embodiment of the present invention.

[0016] BFT protocols are very interesting protocols for use in distributed environments due to the strong guarantees they provide. The two main guarantees of a BFT protocol are security and liveness. Security means that if a valid node in a distributed environment sets a value x, all valid nodes in the environment will ultimately set that value. Furthermore, this value x was proposed by a valid client. Valid clients also agree on values ​​in exactly the same order. Liveness, on the other hand, means that if a valid client issues a request x, the BFT protocol will ultimately agree to that request x.

[0017] These two properties are guaranteed as long as the number of Byzantine nodes (i.e., nodes behaving erratically or maliciously) does not exceed the threshold defined by the protocol. Typical protocols can support up to f Byzantine nodes if the quorum consists of a total of N nodes, with N ≥ 3f + 1. Protocols that employ some additional trust (such as trusted hardware, implemented, for example, as a Trusted Execution Environment (TEE)) can further reduce the limit for N erratically functioning nodes, with N ≥ 2f + 1.

[0018] These properties allow BFT protocols to be used when multiple participants want to collaborate but don't necessarily trust each other completely. The guarantees provided by the BFT protocol ensure that, unless a group of more than f malicious nodes is collaborating, they will not be able to lie or alter the protocol's output.

[0019] Due to the potential presence of adversaries, BFT protocols require many messages and often reach a message complexity of O(n). 2) and are therefore not scalable. Embodiments of the present invention reduce the size of the messages exchanged in the protocol by effectively removing the payload information from the BFT messages and splitting them through a data distribution protocol that ensures weaker properties. Therefore, according to these embodiments, the messages, which have a complexity of O(n 2 ) are subject to, can be drastically reduced, and the useful information can be shared through a simple data distribution protocol with a complexity of O(n).

[0020] In one embodiment, a quorum is assumed to be interested in executing a BFT protocol to order transactions, and its goal is to maximize throughput while minimizing latency. Without loss of generality, it can further be assumed that the protocol has an "optimistic" mode and a "fallback" mode, where the optimistic mode assumes a best-case scenario in which nodes are honest, and the fallback mode assumes that any node can fail or become malicious. The BFT protocol can be designed to automatically switch from optimistic to fallback if too many errors occur, and from fallback to optimistic if the protocol has not detected any errors for a while.

[0021] Embodiments of the invention introduce a general optimization of BFT algorithms by decoupling the data from the actual protocol. The data can then be shared by a certain optimized data propagation algorithm, while the BFT algorithm would only perform consensus on the hash of the data, thereby effectively reducing the message size of the consensus algorithm.

[0022] Reducing the size of the messages in the consensus algorithm reduces the useful information of the messages, which have a complexity of O(n). 2) could be subject to. Even for a BFT protocol using message complexity O(n), it is often the responsibility of one node to perform a 1-to-N broadcast with a message containing the full request. Removing the request from this message effectively improves the efficiency of the 1-to-N broadcast, as it uses much smaller messages. Typically, BFT control messages would be around 100 bytes, while the request can range from a few KB to a few MB. Since the request is propagated by a gossip protocol, this would reduce the load on the node performing the 1-to-N broadcast.

[0023] In principle, the method according to the present invention can be applied to any system that uses a BFT protocol. To give just one example, by using embodiments of the present invention in which the data is decoupled from the actual consensus messages, it would be possible to improve the BFT protocol, for example, of a key-value data store in the cloud.

[0024] According to embodiments of the invention, various gossip protocols can be used for the data layer. Furthermore, each of the various gossip protocols can be used with different levels of strength (with respect to resilience), as explained in more detail below. In the terminology used here, the node that receives the data, e.g., by means of a "broadcast" request, is referred to as the "primary" node. According to the invention, resilience can be added to each of these protocols by adding a certain "Inv" message that could be broadcast to all participating nodes, as is known in the art. An Inv message can be designed to broadcast only the H Datento contain and therefore be very small (approximately 40 bytes). This Inv message could be used to announce the availability of a node to handle the data. According to the invention, upon receiving an Inv message, a node starts a timer. If, at the end of this timer, the data corresponding to the Inv message has still not been received via the currently used standard gossip protocol, the node reaches a time limit and requests the data from a peer that has announced an Inv message.

[0025] The following data dissemination protocols can be selected for use as the data-layer gossip protocol. As experts will recognize, the following list is not exhaustive, and depending on the specific application scenario, other protocols not explicitly mentioned here can be implemented similarly.

[0026] FNF (Fastest Node First) is a data distribution algorithm where requests are continuously uploaded to the node with the highest bandwidth / lowest latency known to each node. The upload order is determined in the configuration using network statistics and assuming that the network state does not change significantly. FNF is useful for minimizing the latency required to execute a request.

[0027] X-aryTree: According to this protocol, nodes are arranged in a balanced tree where each non-leaf node has up to X children. The primary node sits at the root of the tree and sends transactions round-trip via its children. When requests are chained, X-aryTree achieves a trade-off between throughput and latency. If X equals 2, this produces a standard, well-known binary tree.

[0028] X-trees: In X-trees, all nodes (except the primary) are set up in X X-ary trees, where each node is a non-leaf node exactly once. Upon receiving requests, the primary sends a request round through each X-ary tree. This optimization of X-ary trees stems from the observation that in an X-ary tree, leaf nodes never use their upload bandwidth to send data to anyone. By creating multiple X-ary trees, where each node is a non-leaf node exactly once, the protocol can optimize resource usage by the different nodes. In X-ary trees, each node must upload data to X children for every X requests.

[0029] Redundant Mesh: The redundant mesh is based on an Xary tree, except that nodes can potentially have multiple parents. This mesh is useful for adding redundancy by default, instead of having to wait for nodes to reach time limits and request data from a certain received Inv.

[0030] Multicast: The IP layer's multicast functionality could also be used to perform 1-to-N multicast directly, effectively reducing the load on all nodes since this step would only require one node to upload the data once. However, multicast is only available in LANs or environments where the consortium of nodes has full control over switches and routers. Since this is not often the case in WANs, this possibility is limited to very few scenarios.

[0031] According to one embodiment, the data plane can implement two or more of the aforementioned algorithms (or even all of them) to provide flexibility for the BFT protocol. The primary node can then select one of the implemented protocols for use, depending on the application scenario and the relevant conditions.

[0032] Fig. Figure 1 shows an embodiment of the present invention, wherein a specific network topology 1 is assumed, comprising, as shown, a number of network nodes 2 (Node 1, ..., Node 7), with Node 1 acting as the primary node 3. In the illustrated embodiment, the system includes a topology-aware component 4 implemented in the data plane, which is aware of the current network topology. The topology-aware component 4 is designed to select which data propagation protocol should be used and to configure the protocol. The selection of the data propagation protocol to be used can be based on network statistics, such as the throughput and latency between any two nodes 2, and on an optimization parameter, e.g., minimizing latency, maximizing throughput, or a well-defined combination of two or more optimization parameters.

[0033] According to one embodiment, the topology-aware component 4 can be designed to also integrate a feedback loop that compares the expected network statistics, particularly latency and throughput, against the actual values. The result of this comparison can be used to adjust the network. The feedback loop would help address network changes, as it could detect sudden network slowdowns of certain peers and effectively restructure the network. Restructuring the network could, for example, include removing pushing nodes 2 that are very slow compared to leaves of the tree.

[0034] According to one embodiment, the topology-aware component 4 can be as in Fig. Figure 1 is used. As shown in Figure 1, in a first step the topology-aware component 4 is preconfigured, i.e., the topology-aware component 4 receives a certain configuration, including the network statistics and a certain parameter, such as which metric is to be optimized (e.g., latency minimization, throughput maximization, or the like) and the required level of resilience.

[0035] Based on its received configuration, the topology-aware component 4 performs certain simulations to determine which gossip protocol to use. The protocol name of the resulting gossip protocol, as well as the protocol parameters to be used, are then transmitted within the network, for example, directly to the primary node 3, as specified in step 2.

[0036] As shown in step 3, based on the information received from topology component 4, node 2 can start the Gossip protocol using the defined parameters.

[0037] As shown in step 4, topology component 4 can further be configured to periodically collect feedback from the various nodes 2 and monitor performance to detect network changes. If topology component 4 detects a problem, such as a discrepancy (exceeding a preconfigured threshold) between expected and achieved throughput, it can issue update messages to either adjust the configuration parameters of the currently used data propagation protocol or to suggest using a different data propagation protocol that better meets the optimization metric in light of the detected network changes.

[0038] Although the embodiment of Fig. Since the topology-aware component 4 shown in Figure 1 is a discrete entity, it should be noted that, according to an alternative embodiment, the topology-aware component 4 can simply be integrated into the data distribution client of all peers / nodes 2. Furthermore, it should be noted that using a centralized third party as the topology component 4 does not create any security risk, as the topology component 4 only affects performance. If the performance is unsatisfactory, it is expected that the topology component 4 would be modified or removed.

[0039] According to embodiments of the invention, several dedicated application programming interfaces (APIs) that support decoupling can be newly generated and introduced at the data level. Before explaining these newly generated APIs, the high-level API of a standard BFT algorithm is briefly described. For better understanding, but without loss of generality, this description simplifies the BFT protocol API to the functions required by a BFT protocol integrated into a blockchain. As is apparent to those skilled in the art, a standard BFT protocol could further contain a key-value store for issuing read / write requests, as well as rules of validity for these requests, etc.

[0040] Traditionally, a standard BFT protocol displays two main API functions, as follows: - Broadcasting <tx>This API is designed for use by a client to issue a broadcast request for a transaction Tx. The consensus algorithm then runs to agree on the order of this Tx. - Delivery <Tx, π Tx This API is designed for use by the nodes of the protocol to deliver the transaction Tx to all clients after consent has been obtained, as well as a proof π. Tx , that consensus has been reached regarding this transaction Tx.

[0041] According to embodiments of the present invention, the data layer can be designed to expose one or more of the following APIs: - Broadcasting <daten>This API is designed for use by a node to broadcast data (a transaction request) using the underlying Gossip protocol. - Subscribe <H data , Callback>: This API is designed for use by a node to trigger the callback upon receiving the data associated with H Daten agree (where H Daten (which means the hash value of the data). - Data retrieval <H Daten This API is designed for use by a node to actively request the H Daten matching data from other nodes. - Set configuration <config>This API is designed for use in configuring the Gossip protocol (e.g., optimizing latency versus throughput, selecting load levels, selecting time limits, etc.).

[0042] As mentioned previously, according to one embodiment, the topology-aware component 4 can be configured to select a protocol to be used for data distribution among the participating nodes 2 of the BFT protocol from a pre-implemented pool of various data distribution products. For this purpose, the topology component 4 can take as input a parameter to be optimized, possibly together with a resilience level, in addition to network statistics. The parameter to be optimized can be, for example, resilience, latency, or throughput.

[0043] The topology-aware component 4 can be designed to apply certain rules to decide which data propagation algorithm to choose. For example, the following rules can be defined for the respective optimization parameters: Resilience: This parameter may be selected when encountering a network that is unstable and potentially contains many adversaries. In this case, the mesh network should be preferred, as it provides a default level of load, in addition to the Inv messages. This reduces latency variation. According to one embodiment, this data propagation protocol (referred to as the "redundant mesh" protocol in the protocol list above) can be used predominantly when the BFT algorithm switches from an optimistic mode to a fallback mode. Latency: If the BFT layer is not operating under heavy load, but consensus on every request must be achieved with the lowest possible latency, the fnf network should be preferred, as it is optimized for such a use case. It should be noted that in this case, latency is optimized at the expense of throughput, since transactions cannot be chained as easily. Throughput: When optimizing for throughput, the chosen network should ideally always be a tree-based topology, such as X-Trees. X-Trees maximizes network throughput by utilizing the resources of all nodes simultaneously and chaining requests by routing them through different trees.

[0044] It should be noted that for each of the aforementioned cases, it is also possible to add a resilience level using "Inv" messages. In this context, a level of 2 means that, in addition to receiving the request from its parent, each node receives an "Inv" from another (non-parent) node. A resilience level of T helps against up to T-1 adversaries in the tree. Since Inv messages are very inexpensive and do not cause any significant delay, it is suggested to always have a resilience level of approximately f, where f is the number of tolerable adversaries, according to the relation N ≥ 3. * f + 1 (where N is the number of participating nodes).

[0045] The performance improvement achieved by applying the optimization depends on the design and implementation of the BFT protocol. For the following explanations of the performance gains, a (albeit small) standard blockchain design is assumed, comprising 20 nodes, 1 MB transactions (blockchain blocks), and a 100-byte BFT protocol message size.

[0046] PBFT is typically a BFT protocol that handles a number of messages on the order of O(n). 2 This requires that the clients first send the request to all N nodes, then the nodes all send the full request around in a "Prepare" message, and finally, the node sends a "Commit" message around again before returning the result to the client. The amount of data that a node must upload to other nodes is N* (transaction size + message size), so each node must upload at least 20 MB of data for the Prepare message alone.

[0047] Considering a simple binary tree topology, the amount of data that needs to be uploaded by non-leaf nodes is 2 MB, and the data uploaded by leaf nodes consists only of the protocol messages N * 100 bytes = 2 KB. This represents a 90% reduction in message upload for non-leaf trees and a 99.99% reduction for leaf nodes. Furthermore, using a 2-tree with two binary trees would result in an average reduction in data consumption of 95% across all nodes.

[0048] Fig. Figure 2 schematically shows a transaction flow when using FNF for the data layer according to an embodiment of the present invention. Fig. 2. Data-level messages are generally indicated with solid arrows, while control-level messages are indicated by dashed arrows. The same reference numbers denote the same components, as in Fig. 1.

[0049] As shown in Step 1, the BFT protocol is initiated when a client 5 sends a transaction request Tx to network 1. The request is received by node 1, which acts as primary node 3 and first calls the data plane protocol's broadcast API (see Step 2 in Fig. 2) In the example shown, it is assumed that the FNF (Fastest Node First) data distribution algorithm is selected for application.

[0050] At the same time, as shown in step 3, the primary 3 begins to reach a consensus regarding the hash of the request H. Tx using the BFT protocol's broadcast API. Depending on the BFT protocol, this request can be broadcast directly from the primary node 3 to each node 2, or it can use a different scheme.

[0051] As in Fig. As shown in 4, wait for each node 2 upon receiving the BFT request to H Tx the nodes 2 on it, H Tx to receive it by subscribing, using the subscribers <H Tx >-API of the data layer API.

[0052] As shown in step 5, upon receiving the Tx from the data plane, node 2 can continue running the BFT protocol and process the consensus message.

[0053] Experts in the field of the invention will, based on the teachings presented in the above description and the accompanying drawings, be able to conceive of many modifications and other embodiments of the invention as described. Therefore, it is understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are to fall within the scope of protection of the appended claims. Although specific terms are used here, they are used only in a generic and descriptive sense and not for the purpose of limitation.< / config> < / daten> < / tx>

Claims

[1] Method for executing a Byzantine Fault Tolerant or BFT protocol among a number of participating nodes (2) of a network (1), wherein the method comprises: Receiving a transaction request by a primary node (3) of the BFT protocol, The primary node (3) applies a data distribution protocol to distribute the transaction request among the participating nodes (2) via a data layer of the network (1), and Generating a hash of the transaction request by the primary node (3) and requesting consensus among the participating nodes (2) via a control plane of the network (1) using the hash of the transaction request, wherein the data processing protocol includes a resilience improvement mechanism, wherein the mechanism includes broadcasting Inv messages announcing the availability of a node (2) in the network (1) to serve the transaction request, wherein a node (2) starts a timer in response to receiving an Inv message and, if the transaction request corresponding to the Inv message has still not been received by the normal data processing protocol when this timer expires, the node (2) requests the transaction request from a node (2) that has broadcast an Inv message. [2] Method according to claim 1, wherein a number of different data distribution protocols are pre-implemented in the data plane, the method further comprising: Selecting a data distribution protocol to be used by the primary node (3) to distribute the transaction request among the participating nodes (2) from the number of pre-implemented data distribution protocols. [3] Method according to claim 2, wherein the pre-implemented data distribution protocols may include a Fastest-Node-First FNF data distribution protocol, an X-ary-Tree data distribution protocol, an X-Trees data distribution protocol, a mesh redundancy data distribution protocol and / or a multicast data distribution protocol. [4] Method according to any one of claims 1 to 3, further comprising: Providing network statistics and / or network configuration information through a network topology-aware component implemented in the data plane (4), the selection of the data distribution protocol to be used to distribute the transaction request among the participating nodes (2) is based on the provided network statistics and / or network configuration information. [5] Method according to any one of claims 1 to 4, further comprising: Monitoring network performance by a network topology-aware component (4) particularly with regard to latency and / or throughput by collecting feedback information from the participating nodes (2) and In the event of detection that a change in network performance exceeds a predefined threshold, issue an update message to adjust the data propagation protocol to be used to distribute the transaction request among the participating nodes (2). [6] Method according to any one of claims 1 to 5, wherein the data layer exposes a broadcast application programming interface (API) for broadcasting data using the applicable data distribution protocol. [7] Method according to any one of claims 1 to 6, wherein the data plane exposes a subscription API designed to release participating nodes (2) when a BFT request is received in response to a transaction request, in order to wait for the receipt of the hash of the respective transaction request by subscribing to the transaction request. [8] Method according to any one of claims 1 to 7, wherein the BFT protocol comprises an optimistic execution mode and a fallback execution mode, wherein the optimistic execution mode assumes a most-case scenario in which the participating nodes (2) are honest, and wherein the fallback execution mode assumes that any participating node (2) may fail or become malicious, wherein the method comprises: Switching from optimistic to fallback execution mode when the number of errors exceeds a configurable threshold, and switching from fallback to optimistic execution mode when no errors are detected for a configurable period. [9] Method according to claim 5, wherein the network performance includes latency and / or throughput. [10] System for executing a Byzantine Fault Tolerant or BFT protocol in a network (1), wherein the system comprises a number of nodes (2) participating in the BFT protocol, wherein the number of participating nodes (2) includes a primary node (3) of the BFT protocol, which is designed to Receiving a transaction request, Distributing the transaction request among the participating nodes (2) via a data layer of the network (1) using a data distribution protocol, Generating a hash of the transaction request and Requesting consensus among the participating nodes (2) via a control plane of the network (1) using only the hash of the transaction request, wherein the data processing protocol includes a resilience improvement mechanism, wherein the mechanism includes broadcasting Inv messages announcing the availability of a node (2) in the network (1) to serve the transaction request, wherein a node (2) starts a timer in response to receiving an Inv message and, if the transaction request corresponding to the Inv message has still not been received by the normal data processing protocol when this timer expires, the node (2) requests the transaction request from a node (2) that has broadcast an Inv message. [11] System according to claim 10, further comprising a network topology-aware component (4) implemented in the data plane of the network (1) and designed to Receiving network statistics regarding throughput and / or latency between each pair of participating nodes (2), Receiving configuration settings, including an optimization parameter that specifies a metric to be optimized, and Selecting a specific data distribution protocol to be used to distribute the transaction request among the participating nodes (2) based on network statistics and configuration settings. [12] System according to claim 11, wherein the network topology-aware component (4) is designed to Monitoring network performance, particularly with regard to latency and / or throughput, by collecting feedback information from the participating nodes (2) and If it is detected that a change in network performance exceeds a predefined threshold, issue an update message to adjust the data propagation protocol to be used to distribute the transaction request among the participating nodes (2). [13] System according to any one of claims 10 to 12, wherein the data layer exposes a broadcast application programming interface (API) for broadcasting data using the applicable data distribution protocol. [14] System according to any one of claims 10 to 13, wherein the data plane exposes a subscription API designed to release participating nodes (2) when a BFT request is received in response to a transaction request, in order to wait for the receipt of the hash of the respective transaction request by subscribing to the transaction request. [15] System according to claim 12, wherein the network performance includes latency and / or throughput. [16] Network node designed to act as the primary node (3) of a Byzantine Fault Tolerant or BFT protocol in a method according to any one of claims 1 to 9.

Images