Common use of Motivation Clause in Contracts

Motivation. Byzantine agreement (BA) and secure multi-party computation (MPC) are two fundamental and widely explored problems in distributed computing and cryptography. The general problem of MPC allows a set of n parties to correctly carry out an arbitrary computation, without revealing anything about their inputs that could not be inferred from the computed output [45, 46]. Such guarantees must hold even when a subset of the parties are corrupted and actively deviate from the protocol specification. BA can be seen as an instance of MPC, in which the function to evaluate guarantees agreement on a common output [42, 44] and privacy is not a requirement. Protocols for BA are often used as building blocks within larger constructions, including crucially in MPC protocols, and have received renewed attention in the context of blockchain protocols (starting with [38]). There are two prominent communication models in the literature when it comes to the design of such primitives. In the synchronous model, parties have synchronized clocks and messages are assumed to be delivered within some (publicly known) delay ∆. Protocols in this setting achieve very strong security guarantees: under standard setup assumptions, BA [22, 30] and MPC [4, 5, 7, 15, 18, 19, 21, 25, 26, 28, 43] are achievable even when up to t < n/2 parties are corrupted. However, the security of synchronous protocols is often completely compromised as soon as the synchrony assumptions are violated (for example, if even one message is delayed by more than ∆ due to unpredictable network delays). This is particularly undesirable in real- world applications, where even the most stable networks, such as the Internet, occasionally experience congestion or failures. In the asynchronous model, no timing assumptions are needed, and messages can be arbitrarily delayed. Protocols designed in this model are robust even in unpredictable real-world networks, but the security guarantees that can be achieved are ⋆ This work was partially carried out while the author was at ETH Zürich. significantly weaker. For example, protocols in this realm can only tolerate up to t < n/3 corruptions [8, 14, 24]. As a consequence, when deploying protocols in real-world scenarios, one has to decide be- tween employing synchronous protocols —risking catastrophic failures in the case of unforeseen network delays —or settling for the weaker security guarantees of asynchronous protocols.