A General Framework for the Security Analysis of Blockchain Protocols
aa r X i v : . [ c s . D C ] O c t A General Framework for the Security Analysis of BlockchainProtocols *Andrew Lewis-Pye , Tim Roughgarden August 2020 Department of Mathematics, London School of Economics, Columbia House, London, UK. Department of Computer Science, Columbia University, Mudd Building, New York, USA.
Abstract
Blockchain protocols di ff er in fundamental ways, including the mechanics of selecting users toproduce blocks (e.g., proof-of-work vs. proof-of-stake) and the method to establish consensus (e.g.,longest chain rules vs. Byzantine fault-tolerant (BFT) inspired protocols). These fundamental dif-ferences have hindered “apples-to-apples” comparisons between di ff erent categories of blockchainprotocols and, in turn, the development of theory to formally discuss their relative merits.This paper presents a parsimonious abstraction su ffi cient for capturing and comparing proper-ties of many well-known permissionless blockchain protocols, simultaneously capturing essentialproperties of both proof-of-work (PoW) and proof-of-stake (PoS) protocols, and of both longest-chain-type and BFT-type protocols. Our framework blackboxes the precise mechanics of the userselection process, allowing us to isolate the properties of the selection process that are significantfor protocol design.We demonstrate the utility of our general framework with several concrete results that delin-eate which properties are achievable by di ff erent types of blockchains under di ff erent synchronyassumptions. For example: • We prove a CAP-type impossibility theorem asserting that liveness with an unknown level ofparticipation (as in typical PoW protocols) rules out security in a partially synchronous setting(as enjoyed by several BFT-type PoS protocols). • Delving deeper into the partially synchronous setting, we prove that a necessary and su ffi cientcondition for security is the production of “certificates,” meaning stand-alone proofs of blockconfirmation. • Restricting to synchronous settings, we prove that typical protocols with a known level of par-ticipation (including longest chain-type PoS protocols) can be adapted to provide certificates,but those with an unknown level of participation cannot. • Finally, we use our framework to articulate a modular two-step approach to blockchain secu-rity analysis: (i) prove liveness and security properties for a permissioned version of a proto-col; (ii) prove that the method of user selection extends these properties (with high probability)to the original permissionless protocol. * Roughgarden was supported in part by NSF Award CCF-1813188, ARO grant W911NF1910294, and a grant from theColumbia-IBM Center for Blockchain and Data Transparency. Introduction
The task of a permissionless blockchain protocol is to establish consensus for message ordering overa network of users. This job is made di ffi cult by the fact that, being subject to the laws of physics,the underlying communication network must have latency , i.e. broadcast messages will necessarily taketime to travel over the network of users. As a consequence of this latency, malicious users may purposelycause the order in which messages are first seen to vary for di ff erent honest users, and some di ff erencesin ordering will anyway be an honest consequence of varying propagation times between di ff erent nodesof the network [DW13].Network latency is especially problematic when we work at the level of individual transactions, whichmay be produced at a rate which is high compared to network latency. For this reason, it is standardpractice to collect transactions together into blocks , which can then be produced at a rate which is muchlower compared to network latency. Given that we are working in a permissionless setting, the basicquestion then becomes, “Who should produce the blocks?”. In some broad sense all permissionlessprotocols answer this question in the same way. According to one protocol we might select users withprobability depending on their hashing power, while according to another we might select users withprobability proportional to their wealth. Users might be selected one at a time, or they might be selectedin batches and asked to carry out Byzantine-Fault-Tolerant (BFT) protocols defined in the permissionedsetting. In all of these cases, however, we decide upon a method of user selection and then we allowthose selected users to act as permissioned users, giving them roles such as block production, or votingon blocks.The main aim of this paper is to establish a framework for analysing permissionless blockchain pro-tocols that blackboxes the precise mechanics of the user selection process, allowing us to isolate theproperties of the selection process that impact the way in which the protocol must be designed, or thatinfluence properties of the resulting protocol (such as security in a range of synchrony settings). InSection 2 we describe a framework of this kind, according to which protocols run relative to a resourcepool . This resource pool specifies a balance for each user over the duration of the protocol execution(such as hashrate or stake in the currency), which may be used in determining which users are permittedto make broadcasts updating the state. We demonstrate the utility of our general framework with several concrete results that delineate whichproperties are achievable by di ff erent types of blockchains under di ff erent synchrony assumptions. Weprove several results that show how basic properties of the user selection process necessarily impact thesecurity guarantees that can be provided by the protocol; these results demonstrate fundamental di ff er-ences in the security guarantees that can be provided by proof-of-work and proof-of-stake protocols. Wewill be concerned, in particular, with the distinction between scenarios in which the size of the resourcepool is known (e.g. PoS), and scenarios where the size of the resource pool is unknown (e.g. PoW). Weshall refer to the former case as the sized setting and the latter as the unsized setting. Actually, for the sized setting we will require a weaker condition than this – it will su ffi ce, for example, that a function isgiven in advance determining how the total size of the resource pool depends on the set of broadcast messages. CAP-type impossibility result.
By way of introduction, we establish a simple CAP-type theoremfor our framework, which asserts that a protocol cannot be live and secure in the unsized and partiallysynchronous setting.
While similar CAP-type theorems have already been shown for other blockchainframeworks (see, for example, [GPS19, PS17]), the aim here is to begin the process of using our frame-work to formally di ff erentiate the security guarantees that can be achieved by permissionless protocolsusing resource pools with fundamentally di ff erent properties. The hope is that, in particular, this willhelp clarify the di ff erent capabilities of PoW and PoS protocols. The relationship with previous workswill be discussed in greater depth in Section 1.2. Theorem 3.1.
No protocol is live and secure in the unsized and partially synchronous setting.
We shall use the term adaptive as shorthand for “live in the unsized setting” and the term partition se-cure for “secure in the partially synchronous setting.” Theorem 3.1 thus establishes a simple dichotomyfor permissionless blockchain protocols. A protocol can be adaptive or it can be partition secure, butnot both. It also draws a clean and formal line between longest chain protocols such as Bitcoin andEthereum [N +
08, But18], or PoS implementations such as Snow White [BPS16] on the one hand, andBFT protocols such as Algorand [CM19], Casper FFG [BG17] and PoS implementations of Tendermint[Buc16] or Hotstu ff [YMR +
19] on the other. While the former group are all adaptive, the latter groupare all partition secure.
A necessary and su ffi cient condition for partition security. Next we prove a result that, to the bestof our knowledge, has no previous analogues in the literature. Protocols such as Algorand and otherBFT-type protocols achieve partition security through the production of what we shall call certificates .These are sets of broadcast messages whose very existence su ffi ces to establish block confirmation andwhich cannot be produced by a (suitably bounded) adversary given the entire duration of the executionof the protocol. Bitcoin does not produce certificates, because the existence of a certain chain does notprove that it is the longest chain – a user will only believe that a certain chain is the longest chain untilpresented with a longer (possibly incompatible) chain. Algorand does produce certificates, on the otherhand, because the very existence of a certain chain, together with appropriate committee signatures forall the blocks in the chain, can su ffi ce to guarantee (beyond a reasonable doubt) that the blocks in thatchain are confirmed. We will formally define what it means for a protocol to produce certificates inSection 4.The production of certificates is also functionally useful, beyond providing security against networkpartitions. The production of certificates means, for example, that a single untrusted user is able to con-vince another user of block confirmation (by relaying an appropriate certificate), and this is potentiallyvery useful in the context of sharding. If a user wishes to learn the state of a blockchain they were notpreviously monitoring, then it is no longer necessary to perform an onboarding process in which one Liveness and security will be formally defined in Section 2. Roughly, a protocol is live if the number of confirmed blockscan be relied on to increase during extended intervals of time during which message delivery is reliable. A protocol is secureif rollback on confirmed blocks is unlikely. It is standard in the distributed computing literature [Lyn96] to consider a variety of synchronous, partially synchronous ,or asynchronous settings, in which users may or may not have clocks which are almost synchronised, or run at varying speeds,and where message delivery might be reliable or subject to various forms of failure. These terms, together with the sized andunsized settings, will be formally defined in Section 2. Roughly, in the synchronous setting that we consider, there is an upperbound on message delay, while in the partially synchronous setting there may be unbounded network partitions. In the spirit of our investigation, which looks to understand to what extent today’s protocols “haveto look the way they are” given the security guarantees they achieve (as opposed to there being totallyunexplored regions of the protocol design space), a key question is then:Q1. Are certificates fundamental to partition security, or an artifact of Algorand’s specific implemen-tation? That is, are certificates the only way to achieve security in the partially synchronoussetting?Our next result gives an a ffi rmative response to Q1. Theorem 4.1.
If a protocol is partition secure then it produces certificates.
Certificates in the synchronous setting.
Theorem 4.1 shows that the production of certificates isequivalent to security in the partially synchronous setting. But what about Bitcoin? While Bitcoin doesnot satisfy the conditions of Theorem 4.1, it clearly has some non-trivial security. The standard formal-isation in the literature [GKL18, PSS17, Ren19] is that Bitcoin satisfies non-trivial security guaranteesin the synchronous setting , for which there is an upper bound on message delivery time. Even workingin the synchronous setting, though, it is clear that Bitcoin does not produce certificates. Again, we areled to ask whether this is a necessary consequence of the paradigm of protocol design:Q2. Could there be a Bitcoin-like protocol that, at least in the synchronous setting, has as stronga security guarantee in terms of the production of certificates as BFT-type protocols do in thepartially synchronous setting?Again, the crucial distinction is between the sized and unsized settings. The term “non-trivial adver-sary”, which is used in Theorem 6.1 below, will be defined in Section 6 so as to formalise the idea thatthe adversary may have at least a certain minimum resource balance throughout the execution. Withthese basic definitions in place, we can then give a negative answer to Q2.
Theorem 6.1.
Consider the synchronous and unsized setting. If a protocol is live then, in the presenceof a non-trivial adversary, it does not produce certificates.
So, in the unsized setting (in which protocols like Bitcoin operate), useful protocols cannot producecertificates. Following on from our previous discussion regarding the relevance of certificates to shard-ing, one direct application of this result is that it rules out certain approaches to sharding for PoWprotocols. In the sized and synchronous setting, though, it is certainly possible for protocols to producecertificates. It therefore becomes a natural question to ask how far we can push this:Q3. Does the production of certificates come down purely to properties of the process of user selec-tion? Is it simply a matter of whether one is in the sized or unsized setting?Our final theorem gives a form of positive response to Q3. We state an informal version of the theorembelow. A formal version will be given in Section 6. Such techniques can avoid the need to store block hashes in a sharding “main chain,” and the information withholdingattacks that come with those approaches. heorem 6.2 (Informal Version) . Consider the synchronous and sized setting, and suppose a protocolis of ‘standard form’. Then there exists a ‘recalibration’ of the protocol which produces certificates.
Theorem 6.2 says, in particular, that all ‘standard’ PoS protocols can be tweaked to get the strongestpossible security guarantee, since being of ‘standard form’ will entail satisfaction of a number of con-ditions that are normal for such protocols. Roughly speaking, one protocol will be considered to be arecalibration of another if running the former just involves running the latter for a computable transfor-mation of the input parameters and / or using a di ff erent notion of block confirmation. The example ofSnow White may be instructive here. At a very high level, Snow White might be seen as a PoS versionof Bitcoin. It is a PoS longest chain protocol, and it is not di ffi cult to see that, with the standard notion ofconfirmation, it does not produce certificates – an adversary can produce chains of blocks which are not confirmed, but which would be considered confirmed in the absence of other blocks which have beenbroadcast. So whether a block is confirmed depends on the whole set of broadcast messages. On theother hand, it is also not di ffi cult to adjust the notion of confirmation so that Snow White does producecertificates. An example would be to consider a block confirmed when it belongs to a long chain ofsu ffi cient density (meaning that it has members corresponding to most possible timeslots) that it couldnot likely be produced by a (su ffi ciently bounded) adversary. We will see further examples like thisexplained in greater depth in Section 6. Theorem 6.2 implies much more generally that PoS protocolscan always be modified so as to produce certificates in this way.The punchline is that whether or not a protocol produces certificates comes down essentially to whetherone is working in the sized or unsized setting (e.g. whether the protocol is PoS or PoW). This followsfrom the following results that we have already described:(i) According to Theorem 3.1, only protocols which work in the sized setting can be secure in thepartially synchronous setting. According to Theorem 4.1, all such protocols produce certificates.(ii) Theorem 6.1 tells us that, in the synchronous and unsized setting, protocols cannot produce cer-tificates.(iii) Theorem 6.2 tells us that all standard protocols in the sized and synchronous setting can be recal-ibrated to produce certificates. Reducing permissionless to permissioned: A modular approach to blockchain security analysis.
Finally, we show how our framework can be used to reduce the description and analysis of permis-sionless protocols to the permissioned case. This means that describing a permissionless blockchainprotocol and proving that it satisfies basic properties, such as liveness and security, is now broken downinto two tasks:(a) Providing such an analysis for a permissioned reduct , i.e. a permissioned form of the protocol thatwe will describe in Section 7;(b) Specifying and analysing the properties of an appropriate process of user selection, which selectsusers according to their balance as specified by the resource pool.Our work here can be viewed as a common generalization of, for example, the security analyses ofAlgorand in [CM19] and of Bitcoin in [GKL18]. 5 .2 Related Work
While a number of excellent papers (see, for example, [GKL18, PSS17]) describe frameworks for theanalysis of blockchain protocols, to our knowledge the framework presented here is the first to fully for-malise an approach capable of properly modelling all significant features of both PoW and PoS protocolssimultaneously. The most common approach taken in previous papers establishing impossibility resultsis to consider contexts in which a fixed number n of users carry out the protocol, as in the classical dis-tributed computing setting, but where it is now to be understood that the number of users controlled byany individual might depend on a resource such as their computational power. It is a di ffi culty for suchapproaches that, in reality, for PoS protocols the balance of a user will depend on the set of broadcastmessages, and may be recorded di ff erently from the perspective of di ff erent users at a single moment intime. A user’s stake is therefore not a simple function of time, but rather of the set of broadcast messagesseen by a given user – indeed many attacks on PoS protocols [BCNPW19] involve taking advantage ofprecisely this fact. Defining a framework as we do here allows us to overcome this issue, as well asallowing us to formalise notions such as the timed and the sized and unsized settings, that play a crucialrole in the theorems of this paper.The idea of blackboxing the process of user selection as an oracle (akin to our permitter , as describedin Section 2) was explored in [AM + +
17] was to understand the relationship betweenpermissionless and permissioned consensus protocols, but the focus of that paper was somewhat di ff er-ent than our objectives in this paper. While our aim is to describe a framework which is as general aspossible, and to establish impossibility results which hold for all protocols (and with as few assumptionson the process of user selection as possible), the aim of [AM +
17] was to examine specific permissionedconsensus protocols, such as Paxos [L + consistency, availability , and partition tolerance . For formal definitions of these terms werefer the reader to [GL02] and [Lyn96]. Roughly speaking, ‘security’ in our framework corresponds to‘atomic consistency’ in the framework in which the CAP Theorem is proved in [GL02], and ‘liveness’corresponds to ‘availability’. These correspondences are not exact, however. While availability requiresa response even during extended periods of asynchrony, our definition of liveness (see Section 2) ex-plicitly rules out the requirement that new confirmed blocks should be produced under such conditions.The key observation in the proof of Theorem 3.1 is that, in the unsized setting, extended periods ofasynchrony cannot be distinguished from a waning resource pool. Liveness therefore forces the produc-tion of new confirmed blocks during appropriately chosen periods of asynchrony. Liveness and securityare thus incompatible in the partially synchronous and unsized setting, while the same is not true in thepartially synchronous and sized setting.CAP-type theorems have been shown for other blockchain frameworks. In [PS17], for example, it wasshown that if the protocol is unsure about the number of players to a factor of 2 and still needs to provideavailability if between n and 2n players show up, then it is not possible to guarantee security in the event6f network partitions. In [GPS19], the authors developed a useful weakening of the synchronous model,in which honest users need not always be online, but where message delivery and honest participationsu ffi ce to establish consensus protocols that can handle more than 1 / . Whilehonest users may not be online in every round / timeslot, the guarantee is made that, for some χ ∈ [0 , χ fraction of nodes are not only honest but also online in each round. Precisely which set ofhonest nodes are online in each round is controlled by the adversary. For this model, the authors prove aCAP-type theorem establishing that consensus is not possible when χ < − n (with n being the numberof users). The framework is di ff erent than that presented here, but the fundamental reasoning behind theproof is the same as that for Theorem 3.1, and the same as for the proof of the original CAP Theorem[GL02]. The proof of Theorem 3.1 is thus based on well established principles. The point of presentingTheorem 3.1 here is to demonstrate the relevance of the sized and unsized settings, and to show howthey can be used to establish subtle interactions with notions of liveness and security. The sized setting(in which PoS protocols operate) is permissionless, in the sense that one need not know the number ofparticipants or even how the total stake will vary over time in advance of running the protocol. All onerequires is advance knowledge of how a user’s stake is determined by the set of broadcast messages, andthis is enough that PoS protocols can be live and secure in the partially synchronous setting.One consequence of Theorem 3.1 is that Bitcoin is not partition secure. This was proved in [PSS17]. Section 2 describes the basic framework that we shall use in order to blackbox the process of userselection for permissionless blockchain protocols. The partially synchronous, synchronous, sized andunsized settings will be formally defined in this section. We also define what it means for a protocol tobe live, and define our two basic security notions in this section. We prove Theorem 3.1 in Section 3.In Section 4, we define what it means to produce certificates. We show that the two security notionsintroduced in Section 2 are actually equivalent in the partially synchronous setting, and we prove Theo-rem 4.1 for the resulting (single) security notion. In Sections 5 and 6 we then move on to consider thesynchronous setting. In Section 5 we show that, while the two security notions defined in Section 2 arenot equivalent in the synchronous setting, one can establish weak conditions under which they do satisfya form of equivalence. We then prove Theorem 6.1 and Theorem 6.2 in Section 6.In Section 7, we define the notion of a permissioned reduct and show how it can be used to describemodular proofs of liveness and security. In order to demonstrate this point we consider the example ofBitcoin, and show how a modular presentation of the proof of liveness and security from [GKL18] canbe described in terms of a permissioned reduct.Finally, in Section 8, we discuss gaps in the existing analysis, and directions for future research.
So that we can define properties such as liveness and security later on, it will be convenient to considerprotocols that are specified relative to a finite set of input parameters . For Algorand to run securely, Such protocols are not possible in the partially synchronous setting [DLS88]. predetermined . Variables (such as the number ofusers) that are not predetermined, will be referred to as undetermined . Protocols are executed by an undetermined set of pseudonymous users, this set being of undeterminedsize. Each user controls a set of public keys by which they will be known to other users. The variable U is used to range over users, while U will be used to range over public keys – each user may have manypublic keys. Amongst all users, there is one who is distinguished as the adversary and who controls anundetermined set of public keys. Users other than the adversary are called honest .We suppose that each user is a deterministic computing device, which has amongst the actions it canperform calls to certain oracles, as well as certain external functionalities such as the ability to broadcast messages. The protocol specifies an instruction set , which is a program which is run by every user, otherthan the adversary. The adversary can follow any program of their choosing.While we might think of the set of users as forming a network over which messages can propagate,we do not make the network explicit in our framework. Users simply have the ability to broadcast messages. Once a message is broadcast by a public key belonging to a given user, it may subsequentlybe delivered to other users at di ff erent stages of the execution. The protocol gives instructions to be carried out at each in a sequence of timeslots t = , , , . . . . Foreach execution of the protocol, the number of timeslots is given as an input parameter, together witha real time corresponding to each timeslot (i.e. the actual time at which those instructions should becarried out). In order that the execution can actually be carried out, the real time between timeslots musttherefore su ffi ce to carry out the given instructions. The appropriate length of time between timeslotsthus depends on the protocol to be modelled. For many PoS protocols, an appropriate length is slightlymore than the network latency, i.e. the time it takes a block to propagate the network. (Thus, each usermight carry out many instructions during a single timeslot.) We will see that PoW protocols might bebetter modelled using very short timeslots.For a given execution, the sequence of timeslots for which the protocol is to be run is called the duration D . At the beginning of each timeslot in the duration, broadcast messages may be delivered tovarious users. The message state relative to a given user is the set of all broadcast messages which havebeen delivered to them, and is therefore monotonically increasing over time. In order to be broadcast, amessage must be valid , meaning that it must have a certain structure and that certain other conditions,expanded on below, are also satisfied.For example, if modelling Bitcoin or Snow White, a user’s message state will be the set of (valid)blocks that have been delivered to them. Thus the message state will not, in general, be a single chainof blocks. For Algorand, a user’s message state will be all those messages which have been deliveredto them, which are either valid blocks, or else the signed messages of committee members exchangedwhile reaching consensus on blocks. 8t is standard in the distributed computing literature [Lyn96] to consider a variety of synchronous,partially synchronous , or asynchronous settings, in which users may or may not have clocks whichare almost synchronised, or run at varying speeds, and where message delivery might be reliable orsubject to various forms of failure. For the sake of simplicity, we will suppose here that users’ clocksare synchronised. We will, though, allow for periods of network failure, during which the adversary isable to control message delivery. In order to formalise this, we will suppose that the duration is dividedinto intervals that are labelled either synchronous or asynchronous (meaning that each timeslot is eithersynchronous or asynchronous). We will suppose that, during asynchronous intervals, the adversaryis able to interfere with message delivery as they choose, i.e. the adversary can deliver messages whenthey choose, or can stop messages being delivered at all. During synchronous intervals, we shall supposethat messages are delivered within ∆ many timeslots. So ∆ is fixed (and known to the protocol), and if t , t ∈ I for a synchronous interval I , with t − t ≥ ∆ , then any message broadcast at t will be deliveredto all other users by t . It will be convenient to suppose that ∆ ≥ synchronicity settings . In the synchronous setting it is assumed that there areno asynchronous intervals during the duration, while in the partially synchronous setting there may be undetermined asynchronous intervals. Amongst all broadcast messages, there is a distinguished set referred to as blocks , and one block whichis referred to as the genesis block . Unless it is the genesis block, each block B has a unique parent block Par ( B ), which must be uniquely specified within the block message. Each block is produced by a singleuser, Miner ( B ), but may contain other broadcast messages which have been produced by other users.No block can be broadcast by U : = Miner ( B ) at a point strictly prior to that at which its parent has beendelivered to U . Par ( B ) is defined to be an ancestor of B , and all of the ancestors of Par ( B ) are alsodefined to be ancestors of B . If B is not the genesis block, then it must have the genesis block as anancestor. At any point during the duration, the set of broadcast blocks thus forms a tree structure. If M is a set of messages, then we shall say that it is downward closed if it contains the parents of all blocksin M . By a leaf of M , we shall mean a block in M which is not a parent of any block in M . If M isdownward closed and contains a single leaf, then we shall say that M is a chain . Protocols are run relative to a (predetermined or undetermined) resource pool , which in the generalcase is a function R : U × D × M → R ≥ , where U is the set of public keys, D is the duration and M isthe set of all possible sets of messages. So R can be thought of as specifying the resource balance of eachpublic key at each timeslot in the duration, possibly relative to a given message state. For a PoW protocollike Bitcoin, the resource balance of each public key will be their (relevant) computational power at thegiven timeslot (and hence independent of the message state). For PoS protocols, such as Snow White,Ouroboros [KRDO17] and Algorand, however, the resource balance will be fully determined by ‘on-chain’ information, i.e. information recorded in the message state M , and will reflect the user’s currencybalance. As described more precisely in Section 2.6, whether the resource pool is predetermined or determined will decide whetherwe are in the sized or unsized setting.
9y the total resource balance T , we mean the sum of the resource balances of all public keys; this isthe function T : D × M → R ≥ defined by T ( t , M ) = P U R ( U , t , M ). It should be noted that the resourcepool is a variable, meaning that a given protocol may be expected to be live and secure with respect to arange of resource pools. Just as we considered two synchronicity settings earlier, we also consider two resource settings . Thebasic idea is that in the sized setting, the total resource balance is information which is available tothe protocol (and the permitter, as described in Section 2.7), while in the unsized setting it is not. Theprecise details are as follows.
The unsized setting . For the unsized setting, R (and hence T ) is undetermined, with the only restric-tions being:1. R will be a function from U × D × M to R ≥ satisfying the requirement that, at all timeslotsin the duration, the total resource balance belongs to a fixed interval [ R , R ], where R > ffi ciently small and R > R is su ffi ciently large.
2. There may also be bounds placed on the resource balance of the adversary.We shall refer to the set of all resource pools satisfying these restrictions as the possible resourcepools , and, in Section 2.10, we shall define a protocol to be live if it is live for all possible resourcepools.
The sized setting . For the sized setting, the total resource balance T is a predetermined function T : D × M → R ≥ . The basic idea is that PoS protocols will generally be best modelled using the sized setting, whilePoW protocols are best modelled using the unsized setting, since one does not know the total resourcebalance (e.g., total hashrate in each timeslot) in advance.
In order to specify how the resource pool is to be used, we make use of the notion of a permitteroracle . This is the part of the model that blackboxes user selection, since it is the permitter oracle thatgrants permission to broadcast messages. The permitter oracle need not be implemented explicitly inthe blockchain being modelled, and is a mathematical abstraction that allows for the discussion andcomparison of blockchains of very di ff erent types. It is designed to be as simple as possible, subject tothis goal. We consider resource pools with range restricted to the fixed interval [ R , R ] because it turns out to be an overly strongcondition to require a protocol to be live without any further conditions on the total resource balance, beyond the fact that it isa function to R ≥ . We wish to be able to talk about Bitcoin as live in the unsized setting, for example, but liveness will certainlyfail if R is the constant 0 function, or if the total resource balance decreases su ffi ciently quickly over time. Note that, for PoS protocols to operate in the sized setting, we do not require that the total stake (or how it varies overtime) is predetermined. It is enough that we are given a function determining how the total stake depends on the message state.
10s described in Section 2.2, we consider each user to be a computing device with access to certainexternal oracles and functionalities. At any given timeslot t ∈ D , a user’s state is entirely specified by theset of public keys they control, the input parameters, their message state and the set of permissions theyhave been given by the permitter oracle O . The protocol P = ( I , O ) is then a pair, where the instructionset I is a set of deterministic and e ffi ciently computable instructions, which specifies precisely whatactions honest users should carry out at each timeslot, as a function of the timeslot and their state at thattimeslot. The instructions of the protocol are therefore a function of the timeslot, the keys controlled bythe user, the input parameters, their message state, and the set of permissions they have been given bythe permitter.One of the external functionalities each user has is the ability to broadcast valid messages. Amongstthe conditions required for validity is that the public key responsible for the broadcast has been given permission by the permitter oracle O , which is an oracle to which users have access. We thus supposethat users can make ‘requests’ to the permitter, of the form ( U , M , t ′ , A ), where U is a public key undertheir control, M is a possible message state, t ′ is a timeslot, and where A is some (possibly empty)extra data. Given a request of this form, the permitter may then respond by giving them permission tobroadcast certain messages. The response of the permitter to a request ( U , M , t ′ , A ) will be assumed tobe a probabilistic function of the protocol’s input parameters, the actual timeslot t , the previous requestsmade by U , the tuple ( U , M , t ′ , A ), and of the user’s resource balance R ( U , t ′ , M ). It should be noted that the roles of the resource pool and the permitter are di ff erent in the sense that,while the resource pool is a variable (meaning that a given protocol may be expected to be live and securewith respect to a range of resource pools), the permitter is part of the protocol description (meaning thata protocol is only required to run relative to a specific permitter oracle).So far we haven’t described any conditions requiring that the behaviour of the permitter must beinfluenced by the resource pool. Prior to Section 6, the only assumption of this kind that we shall makeis stated below. No balance, no voice : No U will be given permission to broadcast messages in response toa request ( U , M , t ′ , A ) for which R ( U , t ′ , M ) = For concreteness, we next consider how some simple PoS and PoW protocols can be modelled using ourframework. In this section, we will give a brief summary. In Section 7 we give a more in-depth descrip-tion for Bitcoin. We remind the reader that our goal is not to literally model the step-by-step operationof these protocols, but rather to replicate the essential properties of their user selection mechanisms witha suitable choice of a permitter oracle.First, consider a PoW protocol like Bitcoin. To keep things simple, let us ignore Bitcoin’s adjustable‘di ffi culty parameter’ (i.e., how hard the PoW is to produce). To model a simple PoW protocol of thisform, we can consider very short timeslots (say 1 second each, or even shorter). The resource level (i.e.,hashrate) of a user in a given timeslot is independent of the message state, so we can restrict attentionto resource pools R : U × D → R ≥ . We interpret a user request ( U , M , t ′ , A ) in a timeslot t as all of U ’s Another way to interpret these conditions is that the response to a request (or the probability distribution on that response)should be fully determined by information known to the user making the request – in practice, users should be able to checkfor themselves whether or not they have permission to broadcast. ff orts during timeslot t to extend the message state M – if a user submits more than one request duringa timeslot, the permitter ignores all but the first. For example, we can interpret A as a choice and orderingof transactions within a proposed block, along with a choice of predecessor, with the understanding thatthe user will try as many di ff erent nonces as possible during the timeslot. The permitter then gives U permission to broadcast with probability proportional to R ( U , t ) (so long as A can be legally added to M ). A notable feature of this permitter is that permission is granted for the broadcast of specificmessages (i.e., a specific choice of A ), rather than for a collection of messages meeting certain criteria.There are various ways in which ‘standard’ PoS selection processes can work. Let us restrict ourselves,just for now and for the purposes of this example, to considering protocols in which the only broadcastmessages are blocks, and let us consider a longest chain PoS protocol which works as follows: For eachbroadcast chain C and for all timeslots in a set T ( C ), the protocol being modelled selects precisely one public key who is permitted to produce blocks extending C (i.e. blocks whose parent is the unique leafof C ), with the probability each public key is chosen being proportional to their wealth as recorded in C . In order to model a protocol of this form, we can consider a (timeslot-independent) resource pool R : U × M → R ≥ , which takes the longest chain C from M , and allocates to each public key U theirwealth according to C . Then we can consider a permitter which chooses one public key U for eachchain C and each timeslot t ′ in T ( C ), each public key U being chosen with probability R ( U , C ) / T ( C ).(This is well defined because the total resource pool T is known to the protocol.) That chosen publickey U corresponding to C and t ′ , is then given permission to broadcast blocks extending C whenever U makes a request ( U , M , t ′ , ∅ ) for which C is the longest chain in M . A notable feature of this permitter isthat the permission it gives is for the broadcast of sets of messages satisfying certain criteria, i.e. whenthe permitter gives permission it is for any (otherwise valid) block extending a given chain C .To model a BFT PoS protocol like Algorand, the basic approach will be very similar to that describedfor the longest chain PoS protocol above, except that certain other signed messages might be now re-quired in M (such as signed votes on blocks) before permission to broadcast is granted, and permissionmay now be given for the broadcast of messages other than blocks (such as votes on blocks). Formalising di ff erences between PoS and PoW. There are at least three di ff erences that can be identi-fied in the context of our framework, that typically distinguish PoW and PoS protocols: • PoS protocols are generally best modelled in the sized setting, while PoW protocols operate in theunsized setting. Being in the sized setting does not mean that how the total stake varies over timehas to be predetermined information available to the protocol ahead of time. All that is required isknowledge of a function describing how a user’s stake depends upon the message state, and thisis enough to avoid the conclusion of Theorem 3.1, and to allow protocols to be live and secure inthe partially synchronous setting. The parameter t ′ is automatically interpreted as the current timeslot t ; the parameter t ′ is relevant only for PoS protocols. I.e., with probability R ( U , t ) / M , where M is a large constant that depends on an assumed upper bound on hashrate andthe timeslot length. Note that being permitted to broadcast a block is not the same as being instructed by the protocol to broadcast a block,and does not determine how other users will treat the block – there are many contexts in which users might be able to producevalid blocks for which broadcast is not instructed by the protocol (e.g., a block extending a chain other than the longest one).A user may also be permitted to produce two valid blocks whose broadcast constitutes an overt deviation from the protocol,and which might be punished. Note that in many PoS protocols the relevant balance is actually U ’s wealth according to some proper initial segment of C , and that in modelling such protocols one should adjust R accordingly. As mentioned earlier, it is also standard to insist that U has been recorded as a public key with non-zero stake for a minimum number of timeslots. For PoS protocols, blocks cannot lie about their corresponding timeslot. More formally, for eachbroadcast message m , there exists a unique timeslot t m such that permission to broadcast m wasgiven in response to some request ( U , t m , M , A ), and t m is computable from m . We will define thislater as being the conditions required for the timed setting. • PoS protocols are multi-permitters.
This means that, when permission is given to broadcast, it isin response to a request ( U , M , t ′ , ∅ ) in which the last entry is empty. The resultant set of permittedbroadcasts must therefore be a function of the first three entries, which will often mean in practicethat permission has to be granted for a large set of possible broadcasts, such as all blocks extendinga given chain in M . In a PoW protocol, on the other hand, permission to broadcast is made inresponse to a request ( U , M , t ′ , A ), where A can specify a certain block, and the resultant permissioncan be block specific.It is a significant task for future research to further explore the consequences of these di ff erences. Canproperties such as these be used to define the classes of PoW and PoS protocols? In order to define what it means for a protocol to be secure or live, we first need a notion of confirmation for blocks. This is a function C mapping any message state to a chain that is a subset of that messagestate, in a manner that depends on the protocol input parameters, including a parameter ε > security parameter . The intuition behind ε is that it should upper bound the probability of falseconfirmation. Given any message state, C returns the set of confirmed blocks.In Section 2.7, we stipulated that the protocol P = ( I , O ) is a pair, where the instruction set I is aset of deterministic and e ffi ciently computable instructions specifying precisely what actions an honestuser should carry out at each timeslot, and where O is the permitter. In general, however, a protocolmight only be considered to run relative to a specific notion of confirmation C . We will refer to the triple( I , O , C ) as the extended protocol . Often we shall suppress explicit mention of C , and assume it to beimplicitly attached to a given protocol. We shall talk about a protocol being live, for example, when it isreally the extended protocol to which the definition applies. It is important to understand, however, thatthe notion of confirmation C is separate from P , and does not impact the instructions of the protocol. Inprinciple, one can run the same Bitcoin protocol relative to a range of di ff erent notions of confirmation.While the set of confirmed blocks might depend on C , the instructions of the protocol do not.An execution of the extended protocol will depend on the message delivery rule : A message deliveryrule is a partial function d which maps any tuple ( U , m , t , U ′ ), such that U is a public key, m is a possiblemessage, t is a timeslot in the duration, and U ′ is a user, to a timeslot t ′ ≥ t . So a fixed messagedelivery rule determines when each message m , broadcast by U at timeslot t , will be delivered to eachuser U ′ . We restrict attention to message delivery rules which are consistent with ∆ (see Section 2.3),the set of synchronous and asynchronous intervals and the adversary, and which satisfy the conditionthat d ( U , m , t , U ′ ) = t whenever U is a public key controlled by U ′ .Each execution of the extended protocol is then entirely determined by:(I1) The input parameters; Note that a single message delivery rule might result in many di ff erent sequences of message deliveries, if di ff erentsequences of messages are broadcast. Note also that messages are broadcast by keys but delivered to users. I , O , C ), we call a particular set of choices for (I1)- (I5) a protocol instance . Generally, when we discuss an extended protocol, we shall do so within the contextof a setting , which constrains the set of possible protocol instances. The setting might restrict the set ofresource pools to those in which the adversary is given a limited resource balance, for example. Whenwe make a probabilistic statement to the e ff ect that a certain condition holds with at most / least a certainprobability, this means that the probabilisitic bound holds for all protocol instances consistent with thesetting.Where convenient, we may also refer to the pair ( P , C ) as the extended protocol, where P = ( I , O ). There are a number of papers that successfully describe liveness and security notions for blockchainprotocols, see for example [PSS17, GKL18, KRS18]. Our interest here is in identifying the simplestdefinitions that su ffi ce to express our later results. Consider a protocol with a notion of confirmation C ,and let | C ( M ) | denote the number of blocks in C ( M ) for any message state M . For timeslots t < t , let l be the maximum value | C ( M ) | for any M which is a message state of any user at any timeslot t ≤ t ,and let l be the minimum value | C ( M ) | for any M which is a message state of any user at timeslot t .We say that [ t , t ] is a growth interval if l > l . For any duration D , let |D| be the number of timeslotsin D . For ℓ ε, D which takes values in N depending on ε and D , let us say that ℓ ε, D is sublinear in D if,for each ε > α ∈ (0 , ℓ ε, D < α |D| for all su ffi ciently large values of |D| (the motivation forconsidering sublinearity will be described shortly). Definition 2.1.
A protocol is live if, for every choice of security parameter ε > and duration D , thereexists ℓ ε, D , which is sublinear in D , and such that for each pair of timeslots t < t ∈ D the followingholds with probability at least − ε : If t − t ≥ ℓ ε, D and [ t , t ] is entirely synchronous, then [ t , t ] is agrowth interval. So, roughly speaking, a protocol is live if the number of confirmed blocks can be relied on to growover time during synchronous intervals of su ffi cient length. The reason we require ℓ ε, D , to be sublinearin D is so that the number of confirmed blocks likely increases with su ffi cient increase in synchronousduration. For example, a protocol that confirms a block with probability only 2 −|D| at each timeslotshould not be considered live.Generally, assertions of liveness and security will be made within the confines of a particular setting,which might limit the resource balance of the adversary or specify a minimum number of active usersfor each timeslot, for example. Note also, that while Definition 2.1 only refers explicitly to protocols, itis really the extended protocol to which the definition applies. The following stronger notion will alsobe useful. 14 efinition 2.2. A protocol is uniformly live if, for every choice of security parameter ε > and duration D , there exists ℓ ε, D , which is sublinear in D , and such that the following holds with probability at least − ε : For all pairs of timeslots t < t ∈ D , if t − t ≥ ℓ ε, D and [ t , t ] is entirely synchronous, then [ t , t ] is a growth interval. So the di ff erence between being live and uniformly live is that the latter definition requires that, withprobability at least 1 − ε , all appropriate intervals are growth intervals. The former definition onlyrequires the probabilistic bound to hold for each interval individually. An initial impression might bethat it should follow from the Union Bound that Definitions 2.1 and 2.2 are essentially equivalent. Thisis not so. Firstly, this is because the protocol and notion of confirmation take the security parameter ε as input. Nevertheless, one might think that if a protocol is live then a ‘recalibration’, which takes someappropriate transformation of the security parameter as input, should necessarily be uniformly live. Thisdoes not follow (in part) because there is no guarantee that the resulting ℓ ε, D will be sublinear in D –see Section 5 for a detailed analysis. Definition 2.3.
We define a protocol to be adaptive if it is live in the unsized setting.
Roughly speaking, security requires that confirmed blocks normally belong to the same chain. Let ussay that two distinct blocks are incompatible if neither is an ancestor of the other, and are compatible otherwise. If B ∈ C ( M ) where M is the message state of user U at time t , then we shall say that B isconfirmed for U at t . Definition 2.4 (Security) . A protocol is secure if the following holds for every choice of security pa-rameter ε > , for every U , U and for all timeslots t , t in the duration: With probability > − ε , allblocks which are confirmed for U at t are compatible with all those which are confirmed for U at t . The following stronger notion will also be useful.
Definition 2.5 (Uniform Security) . A protocol is uniformly secure if the following holds for every choiceof security parameter ε > : With probability > − ε , there do not exist incompatible blocks B , B ,timeslots t , t and U , U such that B i is confirmed for U i at t i for i ∈ { , } . So the di ff erence between security and uniform security is that the latter requires the probability ofeven a single disagreement to be bounded, while the former only bounds the probability of disagreementfor each pair of users at each timeslot pair. Just as for liveness and uniform liveness, it does not followfrom the Union Bound that security is essentially equivalent to uniform security. In Section 5 we willperform a detailed analysis of the relationship between these notions. Definition 2.6.
A protocol is partition secure if it is secure in the partially synchronous setting. Aprotocol is uniformly partition secure if it is uniformly secure in the partially synchronous setting.
Note that BFT protocols such as Algorand are normally designed to be partition secure.15
The Impossibility of being Adaptive and Partition Secure
Now that the framework and all required definitions are in place, we can formally prove Theorem 3.1.
Theorem 3.1.
No protocol is both adaptive and partition secure.
As stated previously, this theorem can be seen as an analogue of the CAP Theorem [GL02] fromdistributed computing for our framework. Now that we have formally defined adaptivity, security, andliveness, it may be useful to say a little more about the relationship to the CAP Theorem. While the CAPTheorem asserts that (under the threat of unbounded network partitions), no protocol can be both avail-able and consistent, it is possible for BFT protocols such as Algorand to be both live and secure in thepartially synchronous setting . This is possible because liveness is a fundamentally weaker property thanavailability: Liveness does not require new confirmed blocks to be produced during extended periods ofasynchrony. For example, Algorand is live, even though block production may stop during network par-titions. The key idea behind the proof of Theorem 3.1 is that, in the unsized (and partially synchronous)setting, this fundamental di ff erence disappears, with network partitions indistinguishable from waningresource pools. Liveness then forces the existence of growth intervals during network partitions. Inthe unsized and partially synchronous setting, security and liveness thus become incompatible, just asconsistency and availability are incompatible according to the CAP Theorem. Proof. (of Theorem 3.1) The idea behind the proof can be summed up as follows. We consider execu-tions of the protocol in which there are at least two users, both of which are honest, and who controlpublic keys U and U respectively. Suppose that, in an execution of the protocol in the unsized and par-tially synchronous setting, U and U both have the same constant and non-zero resource balance, andthat all other users have resource balance zero throughout the duration. According to the assumption‘no balance, no vote’, this means that U and U will be the only public keys which are able to broadcastmessages. For as long as the adversary is able to prevent messages broadcast by each U i from beingdelivered to U − i ( i ∈ { , } ), the execution will be indistinguishable, as far as U i is concerned, from onein which only U i has the same constant and non-zero resource balance. The fact that the protocol islive means that, with high probability, U and U will see confirmed blocks within a bounded period oftime. The confirmed blocks for U will be incompatible with those for U , so long as these confirmedblocks appear before any point at which a message broadcast by U i has been delivered to U − i for some i ∈ { , } . This contradicts security for the protocol in the partially synchronous setting.To describe the argument in more detail, let U and U be public keys controlled by di ff erent honestusers. For a duration D which is su ffi ciently long, we consider three di ff erent resource pools: R : We let R assign the constant value R > U and U over the entire duration, while allother users are assigned the constant value 0. R : We let R assign the constant value R to U over the entire duration, while all other users areassigned the constant value 0. R : We let R assign the constant value R to U over the entire duration, while all other users areassigned the constant value 0.We consider three di ff erent instances of the protocol with the same parameters, for the unsized settingin which the resource pool is an undetermined variable:16 n : Here R : = R . All timeslots are asynchronous and the adversary prevents the delivery of messagesbroadcast by U i to the user controlling U − i , for i ∈ { , } . In : Here R : = R , and we work in the synchronous setting (or in the partially synchronous setting,but without interference by the adversary). In : Here R : = R , and we work in the synchronous setting.According to the assumption of ‘no balance, no voice’, it follows that only U and U will be able tobroadcast messages in any of these three instances. Our framework stipulates that the instructions of theprotocol for a given user at a given timeslot must be a deterministic function of the protocol parameters,the timeslot, the keys controlled by the user, their message state and the set of permissions they havebeen given by the permitter (see Section 2.7). It also stipulates that the response of the permitter to arequest ( U , M , t ′ , A ) is a probabilistic function of the protocol parameters, the actual timeslot t , previousrequests made by U , the request ( U , M , t ′ , A ), and the user’s resource level R ( U , t ′ , M ). It therefore followsby induction on timeslots that, because the resource pool is undetermined:( † ) For each i ∈ { , } , and for all timeslots in In , the probability distribution on the state of the usercontrolling U i is identical to the corresponding distribution at the same timeslot in In + i .If the protocol is adaptive, then it follows from Definition 2.1 that we can find a timeslot t satisfyingthe following condition: In both In + i ( i ∈ { , } ), it holds with probability > / U i at t . By ( † ) it then holds for In , and for each i ∈ { , } , that withprobability > / U i at t . We stipulated in Section2.4 that no block B can be broadcast by U : = Miner ( B ) at a point strictly prior to that at which itsparent has been delivered to U . It follows that in In all blocks which are confirmed for U i must beincompatible with all blocks which are confirmed for U − i . The definition of security therefore fails tohold for timeslot t , and with respect to the security parameter 1 / (cid:3) The rough idea is that ‘certificates’ should be proofs of confirmation. Towards formalising this idea, letus first consider a version which is too weak.
Definition 4.1.
If B ∈ C ( M ) then we shall refer to M as a subjective certificate for B. We will say that a set of messages M is broadcast if every member is broadcast, and that M is broadcastby timeslot t if every member of M is broadcast at a timeslot ≤ t (di ff erent members potentially beingbroadcast at di ff erent timeslots). If M is a subjective certificate for B , then there might exist M ′ ⊃ M for which B < C ( M ′ ). So the fact that M is broadcast does not constitute proof that C is confirmed withrespect to any user (unless you are that user and you also know that M is your entire message state).When do we get harder forms of proof than subjective certificates? Definition 4.2 below gives a naturaland very simple way of formalising this. Definition 4.2.
We say that a protocol with a notion of confirmation C produces certificates if thefollowing holds with probability > − ε when the protocol is run with security parameter ε : Theredo not exist incompatible blocks B , B , a timeslot t and M , M which are broadcast by t, such thatB i ∈ C ( M i ) for i ∈ { , } .
17t is important to stress that, in the definition above, the M i are not necessarily the message states ofany user, but are rather arbitrary subsets of the set of all broadcast messages. The basic idea is that, ifa protocol produces certificates, then subjective certificates constitute proof of confirmation. Algorandis an example of a protocol which produces certificates: The protocol is designed so that it is unlikelythat two incompatible blocks will be produced at any point in the duration together with appropriatecommittee signatures verifying confirmation for each.Our next aim is to show that, in the partially synchronous setting, producing certificates is equivalentto security. In fact, producing certificates is clearly at least as strong as uniform security, so it su ffi ces toshow that if a protocol is secure then it must produce certificates. Theorem 4.1.
If a protocol is partition secure then it produces certificates.
Proof.
Towards a contradiction, suppose that the protocol with notion of confirmation C is secure in thepartially synchronous setting, but that there exists a protocol instance In with security parameter ε ,such that the following holds with probability ≥ ε : There exist incompatible blocks B , B , a timeslot t and M , M which are broadcast by t , such that B i ∈ C ( M i ) for i ∈ { , } . This means that the followingholds with probability ≥ ε for t last , which is the last timeslot in the duration: There exist incompatibleblocks B , B and M , M which are broadcast by t last , such that B i ∈ C ( M i ) for i ∈ { , } .Consider the protocol instance In which has the same parameters as In , the same adversary, and thesame set of users who are active at the same set of timeslots with the same set of public keys, except thatnow there are two extra users U and U , who are active at all timeslots with keys U and U respectively.Suppose that the resource pool for In is the same as that for In when restricted to public keys otherthan U and U , and that U and U have zero resource balance throughout the duration. Suppose furtherthat the message delivery rule for In is the same as that for In when restricted to tuples ( U , m , t , U ′ )such that U < { U , U } and U ′ < { U , U } , but that now all timeslots are asynchronous (we can supposethat the adversary is such that this message delivery rule is still consistent with the adversary, even whenall timeslots are asynchronous). Our framework stipulates that the instructions of the protocol for a givenuser at a given timeslot must be a deterministic function of the protocol parameters, the timeslot, thekeys controlled by the user, their message state and the set of permissions they have been given by thepermitter (see Section 2.7). It also stipulates that the response of the permitter to a request ( U , M , t ′ , A )is a probabilistic function of the input parameters, the actual timeslot t , previous requests made by U ,the request ( U , M , t ′ , A ), and the user’s resource level R ( U , t ′ , M ). From the assumption ‘No balance,no voice’, it therefore follows by induction on timeslots that the probability distribution on the set ofbroadcast messages is the same at each timeslot for In as for In , independent of which deliveriesthe adversary chooses to make to U and U . It therefore holds for the protocol instance In that withprobability ≥ ε there exist incompatible blocks B , B , and M , M which are broadcast by t last , suchthat B i ∈ C ( M i ) for i ∈ { , } . Suppose that the adversary withholds all messages from U and U until t last , and then delivers M and M (if they exist) to U and U respectively. This su ffi ces to demonstratethat the definition of security is violated with respect to t last , ε , U and U . (cid:3) Corollary 4.3.
Security and uniform security are equivalent in the partially synchronous setting. See Section 2.9 for the definition of a protocol instance. roof. This follows from Theorem 4.1 and the fact that producing certificates clearly implies uniformsecurity. (cid:3)
Theorem 4.1 presents a rather tidy picture for the partially synchronous setting. It is not di ffi cult to see,however, that security and uniform security will not be equivalent in the synchronous setting. To seethis, we can consider the example of Bitcoin. Suppose that we operate in the standard way for Bitcoin,and use a notion of confirmation C that depends only on the security parameter ε , and not on the duration D . In this case, the protocol is secure in the synchronous setting, but will not be uniformly secure in asetting where the adversary controls a non-zero amount of mining power: If a fixed number of blocksare required for confirmation then, given enough time, the adversary will eventually complete a doublespend. It is also clear, however, how to ‘recalibrate’ the protocol to deal with di ff erent durations – tomake the protocol uniformly secure, the number of blocks required for confirmation should be a functionof both ε and D .The aim of this section is formalise the idea of recalibration and to show that, if a protocol is secure,then (under fairly weak conditions) a recalibration will be uniformly secure. The basic idea is verysimple – one runs the initial (unrecalibrated) protocol for smaller values of ε as the duration increases,but one has to be careful that the resulting ℓ ε, D is sublinear in D . Definition 5.1.
We shall say ( P , C ) is a recalibration of the extended protocol ( P , C ) if running P given certain input parameters means running P for a computable transformation of those parameters,and then terminating after |D| many steps are complete. So if running P with security parameter ε and for n many timeslots means running P with inputparameters that specify a security parameter ε/
10 and that specify a duration consisting of 2 n manytimeslots, and then terminating after n many timeslots have been completed, then we might describe P as a recalibration of P . Note also, that we allow the recalibration to use a di ff erent notion ofconfirmation.In the following, we shall say that ℓ ε, D is independent of D if ℓ ε, D = ℓ ε, D ′ for all ε > D , D ′ .When ℓ ε, D is independent of D , we shall often write ℓ ε for ℓ ε, D . Definition 5.2.
In the bounded user setting we assume that there is a finite upper bound on the numberof users, which holds for all protocol instances. Proposition 5.3.
Consider the synchronous and bounded user setting. Suppose P satisfies liveness withrespect to ℓ ε, D , that ℓ ε, D is independent of D , and that for each α > , ℓ ε < αε − for all su ffi cientlysmall ε > . If P is secure, there exists a recalibration of P that is uniformly live and uniformly secure. The conditions on ℓ ε, D in the statement of Proposition 5.3 can reasonably be regarded as weak, becauseexisting protocols which are not already uniformly secure will normally satisfy the conditions that: The reader might wonder why one should specify a duration of 2 n timeslots and then terminate after n many. This isbecause the instructions of the first n timesteps can depend on the intended duration. In Algorand, committee sizes will dependon the intended duration, for example. Note that the requirement here is that the number of users is bounded, rather than the number of public keys. † a ) ℓ ε, D is independent of D , and;( † b ) For some constant c and any ε ∈ (0 , ℓ ε < c ln ε .The example of Bitcoin might be useful for the purposes of illustration here. Bitcoin is secure in thesynchronous setting, and the number of blocks required for confirmation is normally considered to beindependent of the duration. The number of blocks required for confirmation does depend on how sureone needs to be that an adversary cannot double spend in any given time interval, but it’s also true thatan adversary’s chance of double spending in a given time interval decreases exponentially in the numberof blocks required for confirmation as well. So Bitcoin is an example of a protocol satisfying ( † a ) and( † b ) above. Proof of Proposition 5.3.
It is useful to consider a security notion that is intermediate between securityand uniform security. For the purposes of the following definition, we shall say that a block is confirmedat timeslot t if there exists at least one user for whom that is the case. Definition 5.4 (Timeslot Security) . A protocol is timeslot secure if the following holds for every choiceof security parameter ε > , and for all timeslots t , t in the duration: With probability > − ε , allblocks which are confirmed at t are compatible with all blocks which are confirmed at t . So the di ff erence between timeslot security and uniform security is that the latter requires the prob-ability of even a single disagreement to be bounded, while the former only bounds the probability ofdisagreement for each pair of timeslots. Similarly, the di ff erence between security and timeslot securityis that, for each pair of timeslots, the latter requires the probability of even a single disagreement to bebounded, while the former only bounds the probability of disagreement for each pair of users at thattimeslot pair.Now suppose P is live and secure, and that the conditions of Proposition 5.3 hold. Then it followsdirectly from the Union Bound that, if the number of users is bounded, then some recalibration of P is live and timeslot secure and satisfies the conditions of Proposition 5.3. Since a recalibration of arecalibration of P is a recalibration of P , our main task is therefore to show that, if P is live and timeslotsecure and the conditions of Proposition 5.3 hold, then there exists a recalibration of P that is uniformlylive and uniformly secure.So suppose ( P , C ) is live and timeslot secure, and that the conditions of Proposition 5.3 hold. Supposewe are given ε and D as input parameters to our recalibration ( P ′ , C ′ ). We wish to find an appropriatesecurity parameter ε and a duration D ≥ D to give as inputs to P and C , so that uniform security issatisfied with respect to ε and D if we run P with inputs ε and D and then terminate after |D | manytimeslots. The di ffi culty is to ensure that ℓ ε remains sublinear in D . To achieve this, let n : = |D | ,set ε : = ε / n and choose |D | > n + ℓ ε , so that D is the first n timeslots in D . This defines therecalibration. It remains to establish uniform liveness and uniform security.For uniform liveness we must have that, for each α ∈ (0 , ℓ ε < α n for all su ffi ciently large valuesof n – if this condition holds then it follows from the Union Bound that our recalibration will satisfyuniform liveness (and the required sublinearity in D ) with respect to ℓ ′ ε , D : = ℓ ε . The condition holdssince we are given that for each α > ℓ ε < αε − for all su ffi ciently small ε >
0. Suppose given α > α ′ : = αε /
2. Then we have that, for all su ffi ciently large n :20 ε < α ′ ( ε / n ) − = α n . Next we must show that the conditions for uniform security are satisfied. Suppose P is given inputs ε and D and is actually run for |D | many timeslots. We aim to show that, with probability > − ε , theredo not exist incompatible blocks B , B , timeslots t , t ∈ D and U , U such that B i is confirmed for U i at t i for i ∈ { , } . Let t last be the last timeslot of the duration D and define t ∗ : = t last − ℓ ε . The basicidea is that the two following conditions hold with high probability: (i) [ t ∗ , t last ] is a growth interval, and(b) There does not exist t ∈ D , users U , U and incompatible blocks B , B , such that B is confirmedfor U at t and B is confirmed for U at t last . When both these conditions hold, and since t ∗ > n , thissu ffi ces to show that no incompatible and confirmed blocks exist during the duration D . Now let us seethat in more detail.By the choice of D , t ∗ > n . It follows from the definition of liveness that ( ‡ ) below fails to hold withprobability ≤ ε :( ‡ ) [ t ∗ , t last ] is a growth interval.Note that, so long as ( ‡ ) holds, every user has more confirmed blocks at t last than any user does atany timeslot in D . It also follows from the Union Bound, and the definition of liveness and timeslotsecurity, that ( ‡ ) below fails to hold with probability ≤ n ε = ε / ‡ ) There does not exist t ∈ D , users U , U and incompatible blocks B , B , such that B is con-firmed for U at t and B is confirmed for U at t last .Now note that:(a) If ( ‡ ) and ( ‡ ) both hold, then there do not exist incompatible blocks B , B , timeslots t , t ∈ D and U , U such that B i is confirmed for U i at t i for i ∈ { , } .(b) With probability > − ε − ε / ≥ − ε , ( ‡ ) and ( ‡ ) both hold.So uniform security is satisfied with respect to ε and D , as required. (cid:3) Definition 5.5.
We say P has standard functionality if it is uniformly live and uniformly secure. We saythat a recalibration of P is faithful if it has standard functionality when P does. Proposition 5.3 justifies concentrating on protocols which have standard functionality where it isconvenient to do so, since protocols which are live and secure will have recalibrations with standardfunctionality, so long as the rather weak conditions of Proposition 5.3 are satisfied. Again, when we talkabout the security and liveness of a protocol, it is really the extended protocol that we are referring to.
As outlined in the introduction, one aim of this paper is to give a positive answer to Q3, by showing thatwhether a protocol produces certificates comes down essentially to properties of the user selection pro-cess: In the unsized setting protocols cannot produce certificates, while in the sized setting, recalibratedprotocols will automatically produce certificates, at least if they are of ‘standard form’. For the partially21ynchronous setting, the results of Sections 3 and 4 already bear this out – the sized setting is requiredfor security and all secure protocols must produce certificates. The following theorem now deals withthe unsized and synchronous setting. Recall that, in the unsized setting, the total resource balance be-longs to a fixed interval [ R , R ]. We say that the protocol operates ‘in the presence of a non-trivialadversary’ if the setting allows that the adversary may have resource balance at least R throughout theduration. Theorem 6.1.
Consider the synchronous and unsized setting. If a protocol is live then, in the presenceof a non-trivial adversary, it does not produce certificates.
Proof.
The basic idea is that the adversary with resource balance at least R can ‘simulate’ their ownexecution of the protocol, in which only they have non-zero resource balance, while honest users carryout an execution in which the adversary does not participate. Simulating their own execution meansthat the adversary carries out the protocol as usual, while ignoring messages broadcast by honest users,but does not initially broadcast messages when given permission to do so. Liveness (together with thefact that the resource pool is undetermined) guarantees that, with high probability, both the actual andsimulated executions produce blocks which look confirmed from their own perspective. These blockswill be incompatible with each other, and (once the adversary finally broadcasts the messages that theyhave been given permission for), these blocks will all have subjective certificates which are subsets ofthe set of broadcast messages. This su ffi ces to show that the protocol does not produce certificates.More precisely, we consider two instances of the protocol In and In in the synchronous and unsizedsetting, which have the same parameters, including the same small security parameter ε , the same longduration D , the same set of users and the same message delivery rule, but which di ff er as follows: • In In a set of users U control public keys in a set U , which are the only public keys that donot have zero resource balance throughout the duration. The total resource balance T has a fixedvalue, R say. • In In it is the adversary who controls the public keys in U , and those keys have the sameresource balance throughout the duration as they do in In . Now, however, another set of honestusers U control public keys in a set U (disjoint from U ), and the public keys in U have totalresource balance R ≥ R throughout the duration, i.e. the resource balances of these keys alwaysadd to R .In In , we suppose that the adversary simulates the users in U for In , which means that the adversarycarries out the instructions for those users, with the two following exceptions. Until a certain timeslot t ∗ , to be detailed subsequently, they:(a) Ignore all messages broadcast by honest users, and;(b) Do not actually broadcast messages when permitted, but consider them delivered to the simulatedusers in U as per the message delivery rule.For In (so long as the duration is su ffi ciently long), liveness guarantees the existence of a timeslot t for which the following holds with probability > − ε :( ▽ ) At t there exists a set of broadcast messages M and a block B such that B ∈ C ( M ).22or In , liveness guarantees the existence of a timeslot t for which the following holds with probability > − ε :( ▽ ) At t there exists a set of broadcast messages M and a block B such that B ∈ C ( M ).Choose t ∗ > t , t . Our framework stipulates that the instructions of the protocol for a given user at agiven timeslot must be a deterministic function of the input parameters, the timeslot, the keys controlledby the user, their message state and the set of permissions they have been given by the permitter (seeSection 2.7). It also stipulates that the response of the permitter to a request ( U , M , t ′ , A ) is a probabilisticfunction of the protocol input parameters, the actual timeslot t , previous requests made by U , the request( U , M , t ′ , A ), and the resource level R ( U , t ′ , M ). Since we are working in the unsized setting, In and In have the same input parameters. It therefore follows by induction on timeslots t ≤ t ∗ , that the followingis true at all points until the end of timeslot t :( ▽ ) The probability distribution for In on the set of permissions given by the permitter is identicalto the probability distribution for In on the set of permissions given by the permitter to theadversary.Now suppose that at timeslot t ∗ the adversary broadcasts all messages for which they have been givenpermission by the permitter. Note that, according to the assumptions of Section 2.4, any block B broadcast by the adversary at t ∗ will be incompatible with any block B that has been broadcast by anyhonest user up to that point. Combining ( ▽ ), ( ▽ ) and ( ▽ ), we see that (so long as ε is su ffi cientlysmall that ε < − ε ) the following holds with probability > ε for t ∗ and In : There exist incompatibleblocks B , B , and M , M which are broadcast by the end of t ∗ , such that B i ∈ C ( M i ) for i ∈ { , } . Thissu ffi ces to show that the protocol does not produce certificates. (cid:3) The Example of Sized Bitcoin.
Our aim in this subsection is to show that, if we work in the synchronousand sized setting, and if a protocol is of ‘standard form’, then a recalibration will produce certificates.To make this precise, however, it will be necessary to recognise the potentially time dependent natureof proofs of confirmation. To explain this idea, it is instructive to consider the example of Bitcoin inthe sized setting: The protocol is Bitcoin, but now we are told in advance precisely how the hash ratecapability of the network varies over time, as well as bounds on the hash rate of the adversary. To makethings concrete, let us suppose that the total hash rate is fixed over time, and that the adversary has 10%of the hash rate at all times. Suppose that, during the first couple of hours of running the protocol, thedi ffi culty setting is such that the network as a whole (with the adversary acting honestly) will producean expected one block every 10 minutes. Suppose further that, after a couple of hours, we see a block B which belongs to a chain C , in which it is followed by 10 blocks. In this case, the constraints we havebeen given mean that it is very unlikely that B does not belong to the longest chain. So, at that timeslot , C might be considered a proof of confirmation for B , i.e. the existence of the chain C can be taken asproof that B is confirmed. The nature of this proof is time dependent, however. The same set of blocksa large number of timeslots later would not constitute proof of confirmation.If we now consider a PoS version of the example above, modified to work for Snow White rather thanBitcoin, then the proof produced will not be time dependent. This is because PoS protocols are timed , Normally we think of PoW protocols as operating in the unsized setting, precisely because such guarantees on the hashrate are not realistic. m in response to a request ( U , t , M , A ), other users are able todetermine t from m . This is another fundamental distinction between PoW and PoS protocols. Definition 6.1.
We shall refer to the setting as being timed if both of the following hold: • For each broadcast message m, there exists a unique timeslot t m such that permission to broadcastm was given in response to some request ( U , t m , M , A ) . • t m is computable from m. In order to prove that (recalibrated) protocols in the sized setting produce certificates, we shall have tomake the assumption that we are also working in the timed setting.
Protocols in Standard Form.
The basic intuition behind the production of certificates in the sizedsetting can be seen from the example of “Sized Bitcoin” above. Once a block is confirmed, honest userswill work ‘above’ this block. So long as those honest users possess a majority of the total resourcebalance, and so long as the permitter reflects this fact in the permissions it gives, then those honestusers will broadcast a set of messages which su ffi ces (by its existence rather than the fact that it isthe full message state of any user) to give proof of confirmation. This proof of confirmation might betemporary, but it will not be temporary in the timed setting.This intuitive argument, however, assumes that the protocol satisfies certain standard properties. Asalluded to above, there is an assumption that the set of messages broadcast by a group of users willreflect their resource balances and that the adversary will have a minority resource balance. There isalso an assumption that broadcast messages will (in some sense) point to a particular position on theblockchain. So we will have to formalise these ideas, and the results we prove will only hold modulothe assumption that these standard properties are satisfied.First, let us formalise the idea that messages always point to a position on the blockchain. Definition 6.2.
We shall say that a protocol is in standard form if it satisfies all of the following: • The protocol has standard functionality (see Definition 5.5). • Every broadcast message is ‘attached’ to a specific block (blocks being attached to themselves). • While B is confirmed for U, the instruction set I will only instruct U to broadcast messages whichare attached to B or descendants of B. Reflecting the Resource Pool.
Now let us try to describe how the permitter might reflect the resourcepool. We’ll need a simple way to say that one set of users consistently has a higher resource balancethan another.
Definition 6.3.
For Θ > , we say a set of public keys U dominates another set U , denoted U > Θ U , if the following holds for all sets of broadcast messages M and all timeslots t: X U ∈U R ( U , t , M ) > Θ · X U ∈U R ( U , t , M ) . ff erent sets of messages. Recall that, in the timed setting, each message m corresponds to a timeslot t m , which can be determined from m . We shall write M [ t , t ] to denote theset { M | ∀ m ∈ M , t m ∈ [ t , t ] } . We will say that the set of keys U is directed to broadcast M if, forevery m ∈ M , there is some member of U that is given permission to broadcast m and is directed tobroadcast m by the protocol. We will say that U is able to broadcast M if, for every m ∈ M , there issome member of U that is given permission to broadcast m . We define M ∗ : = { M | M is finite } . We let T be the set of functions T : D × M → R ≥ (so that the total resource balance T ∈ T ). We say thata set of keys U has total resource balance T : D × M → R ≥ if T ( t , M ) = P U ∈U R ( U , t , M ). In thedefinition below, we shall say r is sublinear in |D| if, for each Θ , ε, T , and for every α ∈ (0 , r ( Θ , ε, T , |D| ) < α |D| for all su ffi ciently large |D| . Definition 6.4.
We say that ( I , O , C ) reflects the resource pool if there exist computable finite valuedfunctions r : R > × R > × T × N → N and X : R > × R > × T × N → M ∗ , such that:1. r is sublinear in |D| .2. If U ∪ U has total resource balance T , and if U > Θ U , then, when P is run with se-curity parameter ε and for |D| many timeslots, the following holds with probability > − ε :For all intervals of timeslots [ t , t ] with t − t ≥ r ( Θ , ε, T , |D| ) , there exists some element of X ( Θ , ε, T , |D| ) ∩ M [ t , t ] which U is directed to broadcast, while U is not able to broadcastany element of X ( Θ , ε, T , |D| ) ∩ M [ t , t ] . So in Definition 6.4, r specifies a number of timeslots. Then X specifies certain sets of messages M such that, if U > Θ U and U ∪ U has total resource balance T , then U can be expected to broadcastone of these sets M in any interval of su ffi cient length (i.e. the length specified by r ). To make thisinteresting, we also have that U can be expected not to make such broadcasts. To see why this is anatural and reasonable condition to assume, it is instructive to consider the example of Sized Bitcoin.Suppose that in some execution the honest users always have at least 60% of the mining power. Then,over any long period of time r , we can be fairly sure that honest users will get to make at least 50%of the expected number of block broadcasts, while the adversary is unlikely to be able to make suchbroadcasts if r is large enough. In fact, the exponentially fast convergence for the law of large numbersguaranteed by bounds like Hoe ff ding’s inequality, means r only needs to grow with ln 1 / p , where p is the probability of error (i.e. the probability these conditions on the block broadcasts don’t hold in agiven interval). It’s therefore easy to see that Sized Bitcoin would reflect the resource pool if it could beimplemented in a timed setting. Similar arguments can be made for all well known PoS protocols, andthese are implemented in the timed setting. Definition 6.5.
In the bounded adversary setting it is assumed that:(i) U > Θ U for some predetermined input parameter Θ > , where U is the set of keys controlledby honest users, and U is the the set of keys controlled by the adversary.(ii) ( I , O , C ) reflects the resource pool. Finally, we can now formalise the idea that under standard conditions, standard protocols in the sizedsetting produce certificates. Note that this is not the same as 50% of blocks in the longest chain. heorem 6.2. Consider the timed, bounded adversary and sized setting. If P is in standard form, thenthere exists a faithful recalibration that produces certificates. Proof.
To define our recalibration ( P ′ , C ′ ), suppose we are given parameters ε, T , Θ and D . We needto specify a value ε ′ to give as input to P (we will leave other parameters unchanged), and we mustalso define C ′ . Then we need to show that the new extended protocol is uniformly live and producescertificates.We define ε ′ : = ε/
4. Towards defining C ′ , suppose that P satisfies uniform liveness with respect to ℓ ε ′ , D . We divide the duration into intervals of length ℓ ε ′ , D , by defining t i : = i · ( ℓ ε ′ , D + r ( Θ , ε ′ , T , |D| )).From the definition of uniform liveness we have the following.($ ) With probability > − ε/ i with t i ≤ |D| , all users have at least i manyconfirmed blocks by the end of timeslot t i .Now suppose ( P , C ) satisfies Definition 6.4 with respect to r and X . For each i >
0, define t ∗ i : = t i + r ( Θ , ε ′ , T , |D| ). Let I i be the interval [ t i , t ∗ i ], and write M [ I i ] to denote M [ t i , t ∗ i ]. Let U be the set ofkeys controlled by honest users, and let U be the the set of keys controlled by the adversary. Accordingto Definition 6.4, we can then conclude that:($ ) It holds with probability > − ε/ I i is contained in the duration, there exists someelement of X ( Θ , ε ′ , T , |D| ) ∩ M [ I i ] which U is directed to broadcast, while U is not able tobroadcast any element of this set.Since P is uniformly secure, we also know that:($ ) With probability > − ε/
4, there do not exist incompatible blocks B , B , timeslots t , t and U , U such that B i is confirmed for U i at t i for i ∈ { , } .So now define X ∗ ( Θ , ε ′ , T , |D| ) to be all those M in X ( Θ , ε ′ , T , |D| ) for which there exists i such thatall of the following hold:(i) I i ⊆ D .(ii) M ∈ M [ I i ], and;(iii) For some chain C of length i with leaf B , all messages in M are attached B or its descendants.Now if M ∈ X ∗ ( Θ , ε ′ , T , |D| ), then let i M be the (unique) i such that (i)–(iii) hold for i and M , let C beas specified in (iii) for i M , and define C ∗ ( M ) : = C . We also define C ∗ ( ∅ ) = ∅ . This function C ∗ is almostthe notion of confirmation that we want for our recalibration, but the problem is that it is only definedfor very specific values of M . We will use C ∗ to help us define C ′ that is defined for all possible M .Combining ($ ), ($ ) and ($ ), and the definition of X ∗ , it follows that with probability > − ε both ofthe following hold:1. If M , M ′ ∈ X ∗ ( Θ , ε ′ , T , |D| ) are both broadcast, then all blocks in C ∗ ( M ) are compatible with allthose in C ∗ ( M ′ ).2. For every i >
0, there exists M ∈ X ∗ ( Θ , ε ′ , T , |D| ) which is broadcast and such that i M = i .In order to define C ′ for our recalibration, we can then proceed as follows. Given arbitrary M , choose M ′ ⊆ M such that M ′ ∈ X ∗ ( Θ , ε ′ , T , |D| ) and i M ′ is maximal, or if there exists no M ′ satisfying these26onditions then define M ′ : = ∅ . We define C ′ ( M ) : = C ∗ ( M ′ ). It follows from (1) and (2) above that( P ′ , C ′ ) produces certificates and satisfies uniform liveness with respect to ℓ ′ ε, D : = ℓ ε ′ , D + r ( Θ , ε ′ , T , |D| ). (cid:3) An advantage of our framework is the opportunity it provides for modular analysis, by breaking thedescription and evaluation of a permissionless blockchain protocol down into two tasks:(a) Providing such an analysis for a permissioned reduct , i.e. a probability free and (in a sense to beclarified) permissioned form of the protocol that we will describe in this section;(b) Specifying and analysing the properties of an appropriate choice of permitter.In this section we will define permissioned reducts and show how they can be used to formally describethis modular approach. The reader may note that for some BFT-inspired PoS protocols such as Algorand[CM19], this modular approach is already the natural approach taken – to define Algorand one considersa certain BFT protocol in the permissioned setting, and then considers an appropriate process of userselection, giving selected users the task of carrying out the BFT protocol. The keen reader may alsonote that, even where it is not immediately so obvious what such a modular approach might mean (asis the case, for example, with Bitcoin), existing proofs of liveness and security do often end up takingsomething like a modular approach of this form (even if it is not quite so explicit as for our accounthere). It is a benefit of formalising this breakdown through our framework, however, that this reductionto the permissioned case can be seen to hold much more generally. We hope that describing this generalreduction also helps clarify the relationship between permissionless and permissioned protocols.After we have defined permissioned reducts, we will consider the example of Bitcoin. Taking the proofof liveness and security given in [GKL18], we outline how it can be presented in an entirely modularfashion, in which one first deals with a permissioned reduct for Bitcoin, and then proves that livenessand security carry over to the permissionless setting. Roughly, we consider a framework which is the same as that in Section 2, except that the permitter andresource pool are replaced by a deterministic set of rules specifying precisely which keys are allowed tobroadcast and when. In order to make these ideas precise, however, we need a few new definitions.In Section 2 we specified that the response of the permitter to a request ( U , M , t ′ , A ) is a probabilisticfunction of the request and: (i) The protocol’s input parameters; (ii) The actual timeslot t ; (iii) Theprevious requests made by U ; (iv) The resource balance R ( U , t ′ , M ). This response could be permissionto broadcast any and all messages in a certain set, M ′ say. Now consider a pair ( U , D ), where U is a setof keys. A permission table T for the pair is a (deterministic) function that takes any request ( U , M , t ′ , A )together with values for (i)-(iv) above as input (assuming that U ∈ U and t , t ′ ∈ D ), and outputs a value M ′ (which could be empty). We will say that the permission table is consistent with O , if wheneverit outputs a value M ′ , there is always non-zero chance that the permitter O would give permission tobroadcast messages in M ′ in response to those same inputs.So a permission table is a simple object, which can be thought of as a probability free version of the27ermitter. The permission table operates in a permissioned setting, in the sense that the set of keys isgiven as an input before the permission table decides who will be given permission to broadcast andwhen.One final note before we define permissioned reducts: We will consider only protocols that are liveand secure, and can therefore assume that ℓ ε, D has been chosen so as to satisfy Definition 2.1. Apermissioned reduct will be defined relative to this choice of ℓ ε, D . P = ( I , O ) . For a given instance of the protocol, let U be the set of all keys controlled by honest users, let U be theset of all keys controlled by the adversary. We consider a framework which is the same as that describedin Section 2, except that, for each execution of the protocol, permission to broadcast is now determinedby a permission table T for ( U ∪ U , D ) – we shall say that the execution happens relative to T . So nowthe permission table is one of the variables determining the instance, and when a user makes a request( U , M , t ′ , A ) at timeslot t , it is the permission table which dictates the resulting permission to broadcast.When the execution happens relative to a permission table, we will refer to it as a permissioned execution – we will expand on the relationship between permissioned executions and the traditional permissionedsetting later.To define a permissioned reduct PR = ( I , T ) for P = ( I , O ), we replace the permitter O with a function T , which maps each tuple ( U , U , ε, D ), to a set T of permission tables satisfying the conditions that:(i) All T ∈ T are consistent with O , and;(ii) The following probability free versions of liveness and security are satisfied for all possible exe-cutions of the protocol consistent with the setting, so long as U is the set of keys controlled byhonest users, U is the set of keys controlled by the adversary, and so long as the execution isrelative to some permission table for ( U ∪ U , D ) in T . Absolute Liveness.
For each pair of timeslots t < t ∈ D , if t − t ≥ ℓ ε, D and [ t , t ] isentirely synchronous, then [ t , t ] is a growth interval. Absolute Security.
For every U , U and for all timeslots t , t in the duration, all blockswhich are confirmed for U at t are compatible with all those which are confirmed for U at t .For each choice of ℓ ε, D there may therefore be many permissioned reducts. It is clear, however, thatfor each ℓ ε, D there exists a single permissioned reduct which is maximal , in the sense that T maps eachtuple ( U , U , ε, D ) to the set of all T for which absolute liveness and absolute security are satisfied,and which are consistent with O .The reader might find it useful to think of the permissioned reduct as determining a set of ‘good execu-tions’, while simultaneously establishing which permissions to broadcast will result in such executions.While the definition above is quite simple, it may also initially appear a little abstract. An examplewill make things clear. 28 .1.2 Defining a Permissioned Reduct for BitcoinThe model. Before defining the permissioned reduct, we need to decide how we will model Bitcoinas a protocol P = ( I , O ). In Section 2.8 we described a simple approach to modelling Bitcoin. Herewe take the same simple approach, but it will be necessary to flesh out the details of the instruction setsomewhat. We will consider a notion of confirmation that makes Bitcoin uniformly live and uniformlysecure in the synchronous setting.For the sake of concreteness, we fix timeslots of one second each. At each timeslot t , the selectedchain for each user U is the longest chain in their message state – where there is a tie between longestchains, the selected chain is that which was delivered first, with ties between deliveries at the sametimeslot ordered by least hash. At timeslot t , each public key U controlled by U is instructed to putin a single request ( U , M , t , A ), where M is U ’s message state, and where A specifies a block (withoutPoW) extending the selected chain. In response to this request, the permitter may give permission tobroadcast the block. If given permission to broadcast, the instructions dictate that U should then do soimmediately. We work in the synchronous and unsized setting, so that R is undetermined, with the onlyrestrictions being that: • R is assumed to be a function from U × D to R ≥ satisfying the requirement that, at all timeslotsin the duration, the total resource balance belongs to a fixed interval [ R , R ], where R ≥ R > • For some fixed µ >
0, it holds at all timeslots that the adversary controls a proportion at most0 . − µ of the total resource balance. As in [GKL18], bounds have to be placed on µ that onlyallow it to be close to 0 when the ratio between ∆ and the rate at which blocks are produced issu ffi ciently small. We shall not worry about achieving optimal values for µ – see [Ren19] for anexcellent account that considers values for µ in more detail.We suppose we are given two functions N ε, D and ℓ ∗ ε, D such that: • N ε, D defines the notion of confirmation C . More precisely, a user considers block B confirmedonce it belongs to their selected chain, and is followed by at least N ε, D many blocks in that chain. • When the protocol P = ( I , O ) is run with security parameter ε , it holds with probability at least1 − ε/ † ) For every interval of timeslots of length at least ℓ ∗ ε, D , at least one honest user isgiven permission to broadcast a block in that interval.That appropriate values can be chosen for N ε, D and ℓ ∗ ε, D has to be shown later as part of the probabilisticanalysis of the behaviour of the permiiter, once we have dealt with the permissioned reduct. It is worthimmediately understanding the relevance of ℓ ∗ ε, D , however. This value is chosen so as to ensure that itholds with probability at least 1 − ε/ Note that, according to our framework, users do not choose which messages are delivered to them. Of course, theadversary may choose to ignore certain messages, but we shall suppose that the selected chain for any user is defined (asabove) as a function of their sequence of message deliveries. So the adversary does not choose their selected chain, but maychoose to produce blocks that do not extend it. For the sake of notational convenience, we have assumed that µ is fixed as part of the setting here, and so does not needto be specified as another input parameter to the protocol (meaning, for example, that we consider ℓ ε, D rather than ℓ ε, D ,µ ). It isnot di ffi cult, however, to see how our presentation could be modified to deal with varying µ . The same is true for other valuessuch as R , R and ∆ , which we consider for presentational convenience to be fixed, but which could alternatively be specifiedas input parameters. t , t ] of length at least ∆ ∗ : = ℓ ∗ ε, D + ∆ will be a growth interval. This follows since the longest chain C in any user’s message state at t willbe delivered to all users by t + ∆ (to be in a message state, a message has to be broadcast). Then, if( † ) holds, some honest user will broadcast a chain strictly longer than C by t + ∆ + ℓ ∗ ε, D , which willbe delivered to all users by t + ℓ ∗ ε, D + ∆ . Given this analysis, it’s tempting to define ℓ ε, D to be ∆ ∗ . Thedi ffi culty, however, is that we need to allow some initial time for users to build up at least N ε, D manyblocks in their longest chain, so that they begin to have confirmed blocks. For this reason we define: ℓ ε, D : = ( N ε, D + · ∆ ∗ . The permissioned reduct.
We have already specified the instruction set, so it su ffi ces to determinean appropriate set T of permission tables for each tuple ( U , U , ε, D ). For a given execution (whetherpermissioned or relative to the permitter), we let E be the set of all pairs ( U , t ) such that U is givenpermission to broadcast a block B at t – we will refer to B as the block corresponding to ( U , t ). Toestablish absolute security, we will use a version of the approach in [GKL18], simplified since we onlyneed to define and analyse the permissioned reduct at this stage. In particular, this means comparingthe number of blocks that the adversary is permitted to broadcast with the number of blocks that honestusers are permitted to broadcast in isolated intervals: We define ( U , t ) ∈ E to be isolated if U is honestand there do not exist any ( U ′ , t ′ ) ∈ E such that U ′ is honest and t ′ ∈ [ t − ∆ , t + ∆ ]. If ( U , t ) is isolated,then we may also refer to the corresponding block as isolated. If ( U , t ) ∈ E then we may refer to the pairand the corresponding block as honest / dishonest when U is honest / dishonest. The point about isolatedblocks is the following (where the height of a block is its number of ancestors) :( † ) If B is isolated, then any broadcast block B ′ , B of the same height must be dishonest.To prove ( † ), suppose that ( U , t ) is isolated, and that the corresponding block B is of height k . Towardsa contradiction, suppose also that B ′ , B is of height k and is honest. Then B ′ cannot be broadcast strictlyprior to t − ∆ , otherwise B ′ (and all ancestors) would be delivered to the user who controls U before t ,and B would not be broadcast by U at t . Also, B ′ cannot be broadcast during [ t − ∆ , t + ∆ ] because B is isolated. Then we also know that B ′ cannot be broadcast after t + ∆ because it is honest, and B andall ancestors will have been delivered to the honest producer of B by t + ∆ . This gives the requiredcontradiction.For any interval [ t , t ], we define: • X t , t to be the blocks corresponding to pairs ( U , t ) ∈ E such that t ∈ [ t , t ]; • Y t , t to be the blocks corresponding to isolated pairs ( U , t ) ∈ E such that t ∈ [ t + ∆ , t − ∆ ]; • Z t , t to be the blocks corresponding to dishonest pairs ( U , t ) ∈ E such that t ∈ [ t , t ].To define the permissioned reduct, we let T be the set of all permission tables T such that the followingholds for every execution relative to T consistent with the setting:( ⋄ ) T is consistent with O and outputs M ′ = ∅ whenever given input ( U , M , t ′ , A ) at timeslot t , forwhich t ′ , t , or when a previous request has been submitted with respect to U at t .( ⋄ ) For each interval [ t , t ] of length ≥ ℓ ∗ ε, D , there exists at least one honest ( U , t ) ∈ E with t ∈ [ t , t ].30 ⋄ ) For any interval [ t , t ], if | X t , t | ≥ N ε, D then | Y t , t | > | Z t , t | .Roughly, ( ⋄ ) just says that the permission table is like O , in the sense that it only listens to one requestper key at each timeslot, and then only gives permission to broadcast at most a single block at a time(we will specify O precisely in Section 7.2). We will show that ( ⋄ ) su ffi ces to ensure absolute liveness,and we will show that ( ⋄ ) su ffi ces to ensure absolute security. Establishing absolute liveness . In order to prove that T is a permissioned reduct, we must show that itensures absolute liveness and absolute security. To deal with absolute liveness, it is useful to considera weakened version of growth intervals. Let || M || denote the length of the longest chain in M . Fortimeslots t < t , let l be the maximum value || M || for any M which is a message state of any user atany timeslot t ≤ t , and let l be the minimum value || M || for any M which is a message state of anyuser at timeslot t . We say that [ t , t ] is a weak growth interval if l > l . In order to show that absoluteliveness is satisfied, we will prove that: ( † ) So long as T ∈ T , any interval of length ∆ ∗ is a weak growthinterval. This su ffi ces to show absolute liveness, since then, letting t ∗ be the first timeslot at which allusers have a non-empty set of confirmed blocks: • Every interval [ t , t ] with t ≥ t ∗ and of length at least ∆ ∗ is a growth interval. • It follows from the definition ℓ ε, D : = ( N ε, D + · ∆ ∗ and from ( † ) (applied to the first N ε, D · ∆ ∗ timeslots) that ( t ∗ exists and) every interval of length ℓ ε, D contains an interval [ t , t ] with t ≥ t ∗ and of length at least ∆ ∗ .That ( † ) holds follows from precisely the same argument that we described previously in this sub-section, when explaining the relevance of ℓ ∗ ε, D . Consider an interval [ t , t ] of length at least ∆ ∗ . Thelongest chain C in any user’s message state at t will be delivered to all users by t + ∆ . Then it followsfrom ( ⋄ ) that some honest user will broadcast a chain properly extending C by t + ∆ + ℓ ∗ ε, D , which willbe delivered to all users by t + ℓ ∗ ε, D + ∆ = t + ∆ ∗ . Establishing absolute security . For any chain C , let C ∗ be C with the N ε, D many blocks of greatestheight removed. Towards a contradiction, suppose now that absolute security does not hold, so that thereexist U , U , C , C and t , t , such that C is the selected chain for U at t , C is the selected chain for U at t , but C ∗ and C ∗ are incompatible, i.e. neither is an initial segment of the other. Without loss ofgenerality, we may suppose that these values are chosen so that | t − t | is minimal, and so that ( t , t ) isthe lexicographically least possible choice subject to | t − t | being minimal. Let B be the honest blockof greatest height in C ∩ C . Let t be the timeslot at which B is given permission for broadcast (or if B is the genesis block, let t = t and t leaves two possibilities. Either t = t , or else t = t + t = t , and without loss of generality suppose | C | ≥ | C | . It followsfrom ( ⋄ ) that | Y t , t | > | Z t , t | . To obtain a contradiction, it therefore su ffi ces to show that each elementof Y t , t can be paired with a distinct element of Z t , t . To see this, note that none of the blocks in Y t , t can be of height greater than the leaf of C , because this would contradict the fact that C is the selectedchain for U at t . The claim therefore follows from the existence of C and C at t , and from ( † ).Consider next the possibility that t = t +
1. To obtain a contradiction, it su ffi ces to show thateach element of Y t , t can be paired with a distinct element of Z t , t . Now we divide into two subcases.Suppose first that | C | ≤ | C | . In this case, no element of Y t , t can be of height greater than the leaf of C , since this would contradict the fact that C is the selected chain for U at t . As before, the claim31herefore follows from ( † ). Finally, consider the case that | C | > | C | . In this case, no element of Y t , t can be of height greater than the leaf of C , since such blocks must be broadcast at a timeslot ≤ t ,and this would contradict the fact that ( t , t ) was specified as the lexicographically least possible choicesubject to | t − t | being minimal. Once again, the claim therefore follows from ( † ). For a given execution of the protocol, we say that a set of responses from the permitter are consistentwith T if the permission table gives the same responses as the permitter to all sets of inputs given to thepermitter during the course of the execution.Given a permissioned reduct PR = ( I , T ), we have two tasks with respect to the permitter O :1. We must specify how the permitter is defined, i.e. we must specify the distribution on the responseof the permitter given each possible set of inputs.
2. We must show that, when the protocol is run with security parameter ε , it holds with prob-ability > − ε that the permitter produces a set of responses that are consistent with some T ∈ T ( U , U , ε, D ).If we can achieve (2) above, then this su ffi ces to establish uniform liveness and uniform security for theprotocol.For the example of Bitcoin, we have already specified the permitter and the permissioned reduct. So itremains to show that when the protocol is run with security parameter ε , it holds with probability > − ε that the permitter produces a set of responses that are consistent with some T ∈ T ( U , U , ε, D ). Thisnow follows essentially as in [GKL18] (Theorem 31, which establishes that executions are ‘typical’ withhigh probability) from standard concentration bounds. We refer the reader to that paper for the details. The relationship to the permissioned setting.
In the traditional permissioned setting, one can thinkof the set of keys / users as being given as an input parameter. Who is allowed to broadcast and whenis then determined as a function of this input. More generally, the instructions to be carried out mightdepend on the set of users as input, but it is instructive for us now to consider permissioned protocolsin which this input is used only to determine permissions to broadcast. The permissioned reduct, as wehave defined it here, is then a set of permissioned protocols. To deal with the permissionless setting, onedefines a permitter and then shows that, with high probability, it produces responses consistent with oneof the permissioned protocols in that set. There are many ways in which the framework we have presented could be expanded to more accuratelymodel consensus protocols in the permissionless setting. Here we just point out some of the principalweaknesses.
User incentives.
It is generally recognised in the blockchain community that the classical division intohonest and dishonest users is overly simplistic – while the relevance of user incentives is not specific Of course, there is some flexibility in terms of the order in which definitions are given here. One might also specify theprotocol first, and then the permissioned reduct second.
32o the permissionless context, it is nevertheless something which tends to be (rightly) prioritised in thatcontext. In the real world, users are not simply honest or otherwise, and a game theoretic analysiscan give much more robust performance guarantees than reliance on the honesty of certain users. Forthe sake of simplicity, we have omitted any such game theoretic analysis here, but we regard it as animportant task to properly integrate our framework with an appropriate treatment of user incentives.
Realising the permitter.
Part of the strength of the framework we have presented is that it blackboxesthe precise mechanics of the user selection process, allowing us to isolate the properties of the selectionprocess which are significant in the sense that they impact the way in which the protocol must be de-signed, or influence properties of the resulting protocol. This allows us to prove general impossibilityresults. In order to fully specify a usable protocol, however, it remains true that one has to actually implement (an approximation to) the permitter oracle. It would be interesting to extend the frameworkwe have presented here, so as to also formalise the process of permitter implementation. Specifying andanalysing the full protocol would then consist of three tasks:(a) Specifying a permissioned reduct;(b) Specifying and analysing an appropriate permitter oracle;(c) Proving that one can implement an appropriate approximation to the permitter.Again, an advantage of this approach might be in the opportunity it provides for modular analysis –many protocols will use essentially the same method of permitter implementation.
Other performance measures.
For the sake of simplicity, we have concentrated here on the notions ofliveness and security. It is standard in the literature to consider also certain notions of ‘chain quality’(see [GKL18], for example), which require that honest users produce at least a certain proportion of con-firmed blocks. This su ffi ces to ensure that transactions will actually be included in the set of confirmedblocks within a certain bounded time (with high probability). Such considerations are clearly importantfor a rigorous analysis of protocol performance. References [AM +
17] Ittai Abraham, Dahlia Malkhi, et al. The blockchain consensus layer and bft.
Bulletin ofEATCS , 3(123), 2017.[BG17] Vitalik Buterin and Virgil Gri ffi th. Casper the friendly finality gadget. arXiv preprintarXiv:1710.09437 , 2017.[BPS16] Iddo Bentov, Rafael Pass, and Elaine Shi. Snow white: Provably secure proofs of stake. IACR Cryptology ePrint Archive , 2016(919), 2016.[Bre00] Eric A Brewer. Towards robust distributed systems. In
PODC , volume 7, pages 343477–343502. Portland, OR, 2000.[BCNPW19] Jonah Brown-Cohen, Arvind Narayanan, Alexandros Psomas, and S Matthew Weinberg.Formal barriers to longest-chain proof-of-stake protocols. In
Proceedings of the 2019 ACMConference on Economics and Computation , pages 459–473, 2019.33Buc16] Ethan Buchman.
Tendermint: Byzantine fault tolerance in the age of blockchains . PhDthesis, 2016.[But18] Vitalik Buterin. What is ethereum?
Ethereum O ffi cial webpage. Available: http: // / en / latest / introduction / what-is-ethereum. html. Accessed , 14, 2018.[CM19] Jing Chen and Silvio Micali. Algorand: A secure and e ffi cient distributed ledger. Theoreti-cal Computer Science , 777:155–183, 2019.[DLS88] Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. Consensus in the presence of partialsynchrony.
Journal of the ACM (JACM) , 35(2):288–323, 1988.[DW13] Christian Decker and Roger Wattenhofer. Information propagation in the bitcoin network.In
IEEE P2P 2013 Proceedings , pages 1–10. IEEE, 2013.[GKL18] Juan A Garay, Aggelos Kiayias, and Nikos Leonardos. The bitcoin backbone protocol:Analysis and applications. 2018.[GL02] Seth Gilbert and Nancy Lynch. Brewer’s conjecture and the feasibility of consistent, avail-able, partition-tolerant web services.
Acm Sigact News , 33(2):51–59, 2002.[GPS19] Yue Guo, Rafael Pass, and Elaine Shi. Synchronous, with a chance of partition tolerance.In
Annual International Cryptology Conference , pages 499–529. Springer, 2019.[KRDO17] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros:A provably secure proof-of-stake blockchain protocol. In
Annual International CryptologyConference , pages 357–388. Springer, 2017.[KRS18] Lucianna Ki ff er, Rajmohan Rajaraman, and Abhi Shelat. A better method to analyzeblockchain consistency. In Proceedings of the 2018 ACM SIGSAC Conference on Com-puter and Communications Security , pages 729–744, 2018.[L +
01] Leslie Lamport et al. Paxos made simple.
ACM Sigact News , 32(4):18–25, 2001.[Lyn96] Nancy A Lynch.
Distributed algorithms . Elsevier, 1996.[N +
08] Satoshi Nakamoto et al. Bitcoin: A peer-to-peer electronic cash system.(2008), 2008.[PS17] Rafael Pass and Elaine Shi. Rethinking large-scale consensus. In , pages 115–129. IEEE, 2017.[PSS17] Rafael Pass, Lior Seeman, and Abhi Shelat. Analysis of the blockchain protocol in asyn-chronous networks. In
Annual International Conference on the Theory and Applications ofCryptographic Techniques , pages 643–673. Springer, 2017.[Ren19] Ling Ren. Analysis of nakamoto consensus. Technical report, Cryptology ePrint Archive,Report 2019 / // eprint. iacr.org, 2019.[YMR +