Byzantine Generals in the Permissionless Setting

Abstract

In the distributed computing literature, consensus protocols have traditionally been studied in a setting where all participants are known to each other from the start of the protocol execution. In the parlance of the 'blockchain' literature, this is referred to as the permissioned setting. What differentiates the most prominent blockchain protocol Bitcoin [21] from these previously studied protocols is that it operates in a permissionless setting, i.e. it is a protocol for establishing consensus over an unknown network of participants that anybody can join, with as many identities as they like in any role. The arrival of this new form of protocol brings with it many questions. Beyond Bitcoin, what can we prove about permissionless protocols in a general sense? How does recent work on permissionless protocols in the blockchain literature relate to the well-developed history of research on permissioned protocols in distributed computing?To answer these questions, we describe a formal framework for the analysis of both permissioned and permissionless systems. Our framework allows for "apples-to-apples" comparisons between different categories of protocols and, in turn, the development of theory to formally discuss their relative merits. A major benefit of the framework is that it facilitates the application of a rich history of proofs and techniques in distributed computing to problems in blockchain and the study of permissionless systems. Within our framework, we then address the questions above. We consider the Byzantine Generals Problem [19,25] as a formalisation of the problem of reaching consensus, and address a programme of research that asks, "Under what adversarial conditions, and for what types of permissionless protocol, is consensus possible?" We prove a number of results for this programme, our main result being that deterministic consensus is not possible for decentralised permissionless protocols. To close, we give a list of seven open questions.

How Does Blockchain Security Dictate Blockchain Implementation?

“…Our first main result, proved in the context of the framework of [12], gives an affirmative response to Q1. Of course, all terms will be explained and formally defined in later sections.…”

“…A formal framework for comparing design paradigms [12]. While informal, these distinctions are more than aesthetic.…”

“…For example, BFT protocols like Algorand will tend to give security guarantees that hold under significantly weaker network connectivity assumptions than are required to give security for protocols like Bitcoin. By developing an appropriate formal framework, it can then be shown [12] that these differences in security are a necessary consequence of the paradigm of protocol design: The fact that Bitcoin is a PoW protocol means that it cannot offer the same flavour of security guarantees as Algorand. A framework of this kind was developed in [12], according to which permissionless 3 protocols run relative to a resource pool.…”

“…By developing an appropriate formal framework, it can then be shown [12] that these differences in security are a necessary consequence of the paradigm of protocol design: The fact that Bitcoin is a PoW protocol means that it cannot offer the same flavour of security guarantees as Algorand. A framework of this kind was developed in [12], according to which permissionless 3 protocols run relative to a resource pool. This resource pool specifies a balance for each user over the duration of the protocol execution (such as hashrate or stake), which may be used in determining which users are permitted to update state.…”

“…PoW). As per the framework in [12], we will refer to these as the sized and unsized settings, respectively -formal definitions will be given in Section 5. As alluded to above, we define a protocol to be adaptive if it is is live in the unsized setting, and it was shown in [12] that adaptive protocols cannot be secure in the partially synchronous setting.…”