Blockchain Abstract Data Type

Transcription

1 Bockchain Abstract Data Type Emmanuee Anceaume, Antonea De Pozzo, Romaric Ludinard, Maria Potop-Butucaru, Sara Tucci-Piergiovanni CNRS, IRISA CEA LIST, PC 174, Gif-sur-Yvette, 91191, France IMT Atantique, IRISA Sorbonne Université, CNRS, Laboratoire d Informatique de Paris 6, LIP6, Paris, France Abstract The presented work continues the ine of recent distributed computing community efforts dedicated to the theoretica aspects of bockchains. This paper is the first to specify bockchains as a composition of abstract data types a together with a hierarchy of consistency criteria that formay characterizes the histories admissibe for distributed programs that use them. Our work is based on an origina orace-based construction that, aong with new consistency definitions, captures the eventua convergence process in bockchain systems. The paper presents as we some resuts on impementabiity of the presented abstractions and a mapping of representative existing bockchains from both academia and industry in our framework. 1 Introduction The paper proposes a new data type to formay mode bockchains and their behaviors. We aim at providing consistency criteria to capture the correct behavior of current bockchain proposas in a unified framework. It is aready known that some bockchain impementations sove eventua consistency of an append-ony queue using Consensus [6, 5]. The question is about the consistency criterion of bockchains as Bitcoin [25] and Ethereum [30] that technicay do not sove Consensus, and their reation with Consensus in genera. We advocate that the key point to capture bockchain behaviors is to define consistency criteria aowing mutabe operations to create forks and restricting the vaues read, i.e. modeing the data structure as an append-ony tree and not as an append-ony queue. This way we can easiy define a semantics equivaent to eventua consistent append-ony queue but as we weaker semantics. More in detai, we define a semantic equivaent to eventua consistent append-ony queue by restricting any two reads to return two chains such that one is the prefix of the other. We ca this consistency property Strong Prefix (aready introduced in [19]). Additionay, we define a weaker semantics restricting any two reads to return chains that have a divergent prefix for a finite interva of the history. We ca this consistency property Eventua Prefix. Another pecuiarity of bockchains ies in the notion of vaidity of bocks, i.e. the bockchain must contain ony bocks that satisfy a given predicate. Let us note that vaidity can be achieved 1

2 through proof-of-work (Dwork and Naor [15]) or other agreement mechanisms. We advocate that to abstract away impementation-specific vaidation mechanisms, the vaidation process must be encapsuated in an orace mode separated from the process of updating the data structure. Because the orace is the ony generator of vaid bocks and ony vaid bocks can be appended, it foows that it is the orace that grants the access to the data structure and it might aso own a synchronization power to contro the number of forks, in terms of branches of the tree from a given bock. In this respect we define oraces modes such that, depending on the mode, the number of forks from a given bock can be: unbounded, up to k > 1, and k = 1 (no fork) for the strongest orace mode. The bockchain is then abstracted by an orace-based construction in which the update and consistency of the tree data structure depends on the vaidation and synchronization power of the orace. The main contribution of the paper is a forma unified framework providing bockchain consistency criteria that can be combined with orace modes in a proper hierachy of abstract data types [28] independent of the underying communication and faiure mode. Thanks to the estabishment of the forma framework the foowing impementabiity resuts are shown: The strongest orace, guaranteeing no fork, has Consensus number in the Consensus hierarchy of concurrent objects [20] (Theorem 4.2). It must be noted that we considered Consensus defined in [11, 18, 8], in which the Vaidity property states that a vaid bock can be decided even if sent by a fauty process. The weakest orace, which vaidates a potentia unbounded number of bocks to be appended to a given bock, has Consensus number 1 (Theorem 4.3). The impossibiity to guarantee Strong Prefix in a message-passing system if forks are aowed (Theorem 4.8). This means that Strong Prefix needs the strongest orace to be impemented, which is at east as strong as Consensus. A necessary condition (Theorem 4.7) for Eventua Prefix in a message-passing system, caed Update Agreement stating that each update sent by a correct process must be eventuay received by every correct process. The resut impies that it is impossibe to impement Eventua Prefix if even ony one message sent by a correct process is dropped. The proposed framework aong with the above-mentioned resuts heps in cassifying existing bockchains in terms of their consistency and impementabiity. We used the framework to cassify severa bockchain proposas. We showed that Bitcoin [25] and Ethereum [30] have a vaidation mechanism that maps to our weakest orace and then they ony impement Eventua prefix, whie other proposas maps to our strongest orace, faing in the cass of those that guarantee Strong Prefix (e.g. Hyperedger Fabric [5], PeerCensus [12], ByzCoin [23], see Section 5 for further detais). Reated Work. Formaisation of bockchains in the ens of distributed computing has been recognized as an extremey important topic [21]. The topic is recent and to the best of our knowedge, no other attempt proposed a unified framework capturing both Consensus-based and proof-of-work bockchains, as the presented paper aims at proposing. In [1], the authors present a study about the reationship of BFT consensus and bockchains. In order to abstract the proof-of-work mechanism the authors propose a specific orace, in the same spirit of our orace abstraction. Whie their orace is more specific then ours, since it makes a direct reference to proof-of-work properties, it offers as we a fairness property. Note that we do 2

3 not formaize fairness properties in this paper, we ony offer a generic merit parameter that can be used to define fairness. Let us note that apart from the fairness property, our orace captures the semantics of [1] s orace. In parae and independenty of the work in [3], [6] proposes a formaization of distributed edgers modeed as an ordered ist of records. The authors propose in their formaization three consistency criteria: eventua consistency, sequentia consistency and inearizabiity. They discuss how Hyperdger Fabric impements eventua consistency and propose impementations for sequentia consistency and inearizabiity using a tota order broadcast abstraction. Interestingy, they show that a distributed edger that provides eventua consistency can be used to sove the consensus probem. These findings confirm our resuts about the necessity of Consensus to sove Strong Prefix and corroborate our mapping of Hyperedger Fabric. On the other hand the proposed formaization does not propose weaker consistency semantics more suitabe for proof-of-work bockchains as BitCoin. Indeed, [6] continues and it is compementary to the work on the first formaisation of Bitcoin as a distributed edger proposed in [4] where the distributed edger is modeed as a simpe register. These works suggest different abstractions to mode proof-of-work and Consensus-based bockchains, respectivey. The presented paper, on the other hand, thanks to our orace-based construction (not present in [6], [4]) generaizes both [4] and [6] to encompass both kind of bockchains in a unified framework. Finay, [19] presents an impementation of the Monotonic Prefix Consistency (MPC) criterion and showed that no criterion stronger than MPC can be impemented in a partition-prone messagepassing system. Nicey, this resut and more in genera sovabiity resuts for eventua consistency [13] immediatey appy to our Strong Prefix criterion. 2 Preiminaries on shared object specifications based on Abstract Data Types The basic idea underying the use of abstract data types is to specify shared objects using two compementary facets [27]: a sequentia specification that describes the semantics of the object, and a consistency criterion over concurrent histories, i.e. the set of admissibe executions in a concurrent environment. In this work we are interested in consistency criteria achievabe in a distributed environment in which processes are sequentia and communicate through message-passing. 2.1 Abstract Data Type (ADT) The mode used to specify an abstract data type is a form of transducer, as Meay s machines, accepting an infinite but countabe number of states. The vaues that can be taken by the data type are encoded in the abstract state, taken in a set Z. It is possibe to access the object using the symbos of an input aphabet A. Unike the methods of a cass, the input symbos of the abstract data type do not have arguments. Indeed, as one authorizes a potentiay infinite set of operations, the ca of the same operation with different arguments is encoded by different symbos. An operation can have two types of effects. First, it can have a side-effect that changes the abstract state, the corresponding transition in the transition system being formaized by a transition function τ. Second, operations can return vaues taken in an output aphabet B, which depend on the state in which they are caed and an output function δ. For exampe, the pop operation in a stack removes the eement at the top of the stack (its side effect) and returns that eement (its output). 3

4 The forma definition of abstract data types is as foows. Definition 2.1. (Abstract Data Type T ) An abstract data type is a 6-tupe T = A, B, Z, ξ 0, τ, δ where: A and B are countabe sets caed input aphabet and output aphabet; Z is a countabe set of abstract states and ξ 0 is the initia abstract state; τ : Z A Z is the transition function; δ : Z A B is the output function. Definition 2.2. (Operation) Let T = A, B, Z, ξ 0, τ, δ be an abstract data type. An operation of T is an eement of Σ = A (A B). We refer to a coupe (α, β) A B as α/β. We extend the transition function τ over the operations and appy τ on the operations input aphabet: Z Σ Z τ T : (ξ, α) τ(ξ, α) if α A (ξ, α/β) τ(ξ, α) if α/β A B 2.2 Sequentia specification of an ADT An abstract data type, by its transition system, defines the sequentia specification of an object. That is, if we consider a path that traverses its system of transitions, then the word formed by the subsequent abes on the path is part of the sequentia specification of the abstract data type, i.e. it is a sequentia history. The anguage recognized by an ADT is the set of a possibe words. This anguage defines the sequentia specification of the ADT. More formay, Definition 2.3. (Sequentia specification L(T )) A finite or infinite sequence σ = (σ i ) i D Σ, D = N or D = {0,..., σ 1} is a sequentia history of an abstract data type T if there exists a sequence of the same ength (ξ i+1 ) i D Z (ξ 0 has aready been defined has the initia state) of states of T such that, for any i D, the output aphabet of σ i is compatibe with ξ i : ξ i δ 1 T (σ i); the execution of the operation σ i is such that the state changed from ξ i to ξ i+1 : τ T (ξ i, σ i ) = ξ i+1. The sequentia specification of T is the set of a its possibe sequentia histories L(T ). 2.3 Concurrent histories of an ADT Concurrent histories are defined considering asymmetric event structures, i.e., partia order reations among events executed by different processes [27]. Definition 2.4. (Concurrent history H) The execution of a program that uses an abstract data type T = A, B, Z, ξ 0, τ, δ defines a concurrent history H = Σ, E, Λ,,,, where Σ = A (A B) is a countabe set of operations; 4

5 E is a countabe set of events that contains a the ADT operations invocations and a ADT operation response events; Λ : E Σ is a function which associates events to the operations in Σ; : is the process order reation over the events in E. Two events are ordered by if they are produced by the same process; : is the operation order, irrefexive order over the events of E. For each coupe (e, e ) E 2, if e is an operation invocation and e is the response for the same operation then e e, if e is the invocation of an operation occurred at time t and e is the response of another operation occurred at time t with t < t then e e ; : is the program order, irrefexive order over E, for each coupe (e, e ) E 2 with e e if e e or e e then e e. 2.4 Consistency criterion The consistency criterion characterizes which concurrent histories are admissibe for a given abstract data type. It can be viewed as a function that associates a concurrent specification to abstract data types. Specificay, Definition 2.5. (Consistency criterion C) A consistency criterion is a function C : T P(H) where T is the set of abstract data types, H is a set of histories and P(H) is the sets of parts of H. Let C be the set of a the consistency criteria. An agorithm A T impementing the ADT T T is C-consistent with respect to criterion C C if a the operations terminate and a the admissibe executions are C-consistent, i.e. they beong to the set of histories C(T ). 3 BockTree and Token orace ADTs In this section we present the BockTree and the token Orace ADTs aong with consistency criteria. 3.1 BockTree ADT We formaize the data structure impemented by bockchain-ike systems as a directed rooted tree bt = (V bt, E bt ) caed BockTree. Each vertex of the BockTree is a bock and any edge points backward to the root, caed genesis bock. The height of a bock refers to its distance to the root. We denote by b k a bock ocated at height k. By convention, the root of the BockTree is denoted by b 0. Bocks are said vaid if they satisfy a predicate P which is appication dependent (for instance, in Bitcoin, a bock is considered vaid if it can be connected to the current bockchain and does not contain transactions that doube spend a previous transaction). We represent by B a countabe and non empty set of bocks and by B B a countabe and non empty set of vaid bocks, i.e., b B, P (b) =. By assumption b 0 B ; We aso denote by BC a countabe non empty set of bockchains, where a bockchain is a path from a eaf of bt to b 0. A bockchain is denoted by bc. Finay, F is 5

6 append(b 1 )/true if b 1 B append(b 2 )/true read()/b 0 b 1 if b 2 B read()/b 0 b 1 b 2 append(b 3 )/fase append(b 3 )/fase ξ 0 ξ 1 ξ 2 if b 3 / B if b 3 / B ξ 0 = { b0, f, P } ξ 1 = { b0 b1, f, P } ξ 2 = { b0 b1 b2, f, P } Figure 1: A possibe path of the transition system defined by the BT-ADT. We use the foowing syntax on the edges: operation/output. a countabe non empty set of seection functions, f F : BT BC; f(bt) seects a bockchain bc from the BockTree bt (note that b 0 is not returned) and if bt = b 0 then f(b 0 ) = b 0. This refects for instance the ongest chain or the heaviest chain used in some bockchain impementations. The seection function f and the predicate P are parameters of the ADT which are encoded in the state and do not change over the computation. The foowing notations are aso deepy used: {b 0 } f(bt) represents the concatenation of b 0 with the bockchain of bt; and {b 0 } f(bt) {b} represents the concatenation of b 0 with the bockchain of bt and a bock b; Sequentia specification of the BockTree The sequentia specification of the BockTree is defined as foows. Definition 3.1 (BockTree ADT (BT -ADT )). The BockTree Abstract Data Type is the 6-tupe BT-ADT= A = {append(b), read(): b B}, B = BC {true, fase}, Z = BT F (B {true, fase}), ξ 0 = (bt 0, f), τ, δ, where the transition function τ : Z A Z is defined by τ((bt, f, P ), append(b)) = ({b 0 } f(bt) {b}, f, P ) if b B ; (bt, f, P ) otherwise; τ((bt, f, P ), read()) = (bt, f, P ), and the output function δ : Z A B is defined by δ((bt, f, P ), append(b)) = true if b B ; fase otherwise; δ((bt, f, P ), read()) = {b 0 } f(bt); δ((bt 0, f, P ), read()) = b 0. The semantic of the read and the append operations directy depend on the seection function f F. In this work we et this function generic to suit the different bockchain impementations. In the same way, predicate P is et unspecified. The predicate P mainy abstracts the creation process of a bock, which may fai or successfuy terminate. This process wi be further specified in Section

7 3.1.2 Concurrent specification of a BT-ADT and consistency criteria The concurrent specification of the BT-ADT is the set of concurrent histories. A BT -ADT consistency criterion is a function that returns the set of concurrent histories admissibe for a BockTree abstract data type. We define two BT consistency criteria: BT Strong consistency and BT Eventua consistency. For ease of readabiity, we empoy the foowing notations: E(a, r ) is an infinite set containing an infinite number of append() and read() invocation and response events; E(a, r ) is an infinite set containing (i) a finite number of append() invocation and response events and (ii) an infinite number of read() invocation and response events; e inv (o) and e rsp (o) indicate respectivey the invocation and response event of an operation o; and e rsp (r) : bc denotes the returned bockchain bc associated with the response event e rsp (r); score : BC N denotes a monotonic increasing deterministic function that takes as input a bockchain bc and returns a natura number s as score of bc, which can be the height, the weight, etc. Informay we refer to such vaue as the score of a bockchain; by convention we refer to the score of the bockchain uniquey composed by the genesis bock as s 0, i.e. score({b 0 }) = s 0. Increasing monotonicity means that score(bc {b}) > score(bc); mcps : BC BC N is a function that given two bockchains bc and bc returns the score of the maxima common prefix between bc and bc ; bc bc iff bc prefixes bc. BT Strong consistency. The BT Strong Consistency criterion is the conjunction of the foowing four properties. The bock vaidity property imposes that each bock in a bockchain returned by a read() operation is vaid (i.e., satisfies predicate P ) and has been inserted in the BockTree with the append() operation. The Loca monotonic read states that, given the sequence of read() operations at the same process, the score of the returned bockchain never decreases. The Strong prefix property states that for each coupe of read operations, one of the returned bockchains is a prefix of the other returned one (i.e., the prefix never diverges). Finay, the Ever growing tree states that scores of returned bockchains eventuay grow. More precisey, et s be the score of the bockchain returned by a read response event r in E(a, r ), then for each read() operation r, the set of read() operations r such that e rsp (r) e inv (r ) that do not return bockchains with a score greater than s is finite. More formay, the BT Strong consistency criterion is defined as foows: Definition 3.2 (BT Strong Consistency criterion (SC)). A concurrent history H = Σ, E, Λ,,, of the system that uses a BT-ADT verifies the BT Strong Consistency criterion if the foowing properties hod: Bock vaidity: e rsp (r) E, b e rsp (r) : bc, b B e inv (append(b)) E, Loca monotonic read: e inv (append(b)) e rsp (r). e rsp (r), e rsp (r ) E 2, if e rsp (r) e inv (r ), then score(e rsp (r) : bc) score(e rsp (r ) : bc ). 7

8 Strong prefix: e rsp (r), e rsp (r ) E 2, (e rsp (r ) : bc e rsp (r) : bc) (e rsp (r) : bc e rsp (r ) : bc ). Ever growing tree: e rsp (r) E(a, r ), s = score(e rsp (r) : bc) then {e inv (r ) E e rsp (r) e inv (r ), score(e rsp (r ) : bc ) s} <. Figure 2 shows a concurrent history H admissibe by the BT Strong consistency criterion. In this exampe the score is the ength of the bockchain and the seection function f seects the ongest bockchain, and in case of equaity, seects the argest based on the exicographica order. For ease of readabiity, we do not depict the append() operation. We assume the bock vaidity property is satisfied. The Loca monotonic read is easiy verifiabe as for each coupe of read bockchains one prefixes the other. The first read() r operation, encosed in a back rectange, is taken as reference to check the consistency criterion (the criterion has to be iterativey verified for each read() operation). Let be the score of the bockchain returned by r. We can identify two sets, encosed in rectanges defined by different patterns: (i) the finite sets of read() operations such that the score associated to each bockchain returned is smaer than or equa to, and (ii) the infinite set of read() operations such that the score is greater than. We can iterate the same reasoning for each read() operation in H. Thus H satisfies the Ever growing tree property. i read(), =3 b b b t set with each bc score > set with each bc score j b 0 1 b b t Figure 2: Concurrent history that satisfies the BT Strong consistency criterion. In such scenario f seects the ongest bockchain and the bockchain score is ength. BT Eventua consistency. The BT Eventua consistency criterion is the conjunction of the bock vaidity, the Loca monotonic read and the Ever growing tree of the BT Strong consistency criterion together with the Eventua prefix which states that for each bockchain returned by a read() operation with s as score, then eventuay a the read() operations wi return bockchains sharing the same maximum common prefix at east up to s. Say differenty, et H be a history with an infinite number of read() operations, and et s be the score of the bockchain returned by a read r, then the set of read() operations r, such that e rsp (r) e inv (r ), that do not return bockchains sharing the same prefix at east up to s is finite. Definition 3.3 (Eventua prefix property). Given a concurrent history H = Σ, E(a, r ), Λ,,, of the system that uses a BT-ADT, we denote by s, for any read operation r Σ such that e E(a, r ), Λ(r) = e, the score of the returned bockchain, i.e., s = score(e rsp (r) : bc). We denote by E r the set of response events of read operations that occurred after r response, i.e. 8

9 E r = {e E r Σ, r = read, e = e rsp (r ) e rsp (r) e rsp (r )}. Then, H satisfies the Eventua prefix property if for a read() operations r Σ with score s, {(e rsp (r h ), e rsp (r k )) E 2 r h k, mpcs(e rsp (r h ) : bc h, e rsp (r k ) : bc k ) < s} < The Eventua prefix properties captures the fact that two or more concurrent bockchains can co-exist in a finite interva of time, but that y a the participants adopts a same branch for each cut of the history. This cut of the history is defined by a read that picks up a bockchain with a given score. Based on this definition, the BT Eventua consistency criterion is defined as foows: Definition 3.4 (BT Eventua consistency criterion EC). A concurrent history H = Σ, E, Λ,,, of the system that uses a BT-ADT verifies the BT Eventua consistency criterion if it satisfies the Bock vaidity, Loca monotonic read, Ever growing tree, and the Eventua prefix properties. read(), =3 i b b b t set with each bc score > set with each bc score b 0 1 b 0 2 b j i (a) Sets for the Ever Growing Tree property. read(), =3 b b b t t set with bockchains mcps < set with bockchains mcps b 0 1 b 0 2 b j t (b) Sets for the Eventua Prefix Property. Figure 3: Concurrent history that satisfies the Eventua BT consistency criterion. In such scenario f seects the ongest bockchain and the bockchain score is the ength. In case (a) and case (b) the concurrent history is the same but different sets are outined. Figure 3 shows a concurrent history that satisfies the Eventua prefix property but not the Strong prefix one. Strong Prefix is not satisfied as bockchain 1 b 0 1 returned from the first read() at process j is not a prefix of bockchain b returned from the first read at process i. Note that we adopt the same conventions as for the exampe depicted in Figure 2 regarding the score, ength and append() operations. We assume that the Bock vaidity property is satisfied. The 1 For ease of readabiity we extend the notation b i b j to represent concatenated bocks in a bockchain. 9

10 Loca monotonic read property is easiy verifiabe. In both Figures 3a and 3b, the first read() r operation at i, encosed in a back rectange, is taken as reference to check the consistency criterion (the criterion has to be iterativey verified for each read() operation). Let be the score of the bockchain returned by r. In Figure 3b we can identify two sets, encosed in rectanges defined by different patterns: (i) the finite set of read() operations sharing a maximum common prefix score (mcps) smaer than (the set to check for the satisfiabiity of the Eventua Prefix property), and (ii) the infinite set of read() operations such that for each coupe of them bc, bc, mcps(bc, bc ). We can iterate the same reasoning for each read() operation in H. Thus H satisfies the Eventua Prefix property. Figure 4 shows a history that does not satisfy any consistency criteria defined so far. read(), =3 i b b b t set with each bc score > set with each bc score b 0 1 b 0 2 b j i (a) Sets for the Ever Growing Tree property. read(), =3 b b b t t set with bockchains mcps < b 0 1 b 0 2 b j t (b) Sets for the Eventua Prefix Property. Figure 4: Concurrent history that does not satisfy any BT consistency criteria. In such scenario f seects the ongest bockchain and the bockchain score is the ength. Reationships between EC and SC. Let us denote by H EC and by H SC the set of histories satisfying respectivey the EC and the SC consistency criteria. Theorem 3.1. Any history H satisfying SC criterion satisfies EC and H satisfying EC that does not satisfy SC, i.e., H SC H EC. Proof. EC SC impies that H SC H EC, and H SC H EC impies that H H SC H H EC. By hypothesis, H verifies the Ever Growing Tree property, thus e rsp (r) E(a, r ) with s = score(e rsp (r) : bc) then set {e inv (r ) E e rsp (r) e inv (r ), score(e rsp (r ) : bc) s} is finite, and thus, there is an infinite set {e inv (r ) E e rsp (r) e inv (r ), score(e rsp (r ) : bc) > s}. The Strong prefix property guarantees that e rsp (r), e rsp (r ) H, (e rsp (r) : bc e rsp (r) : bc ) (e rsp (r) : 10

11 bc e rsp (r ) : bc ), thus in this infinite set, a the read() operations return bockchains sharing the same maximum prefix whose score is at east s+1, which satisfies the Eventua prefix property. The Eventua Prefix property demands that for each e rsp (r) E(a, r ) with s = score(e rsp (r) : bc) there is an infinite set defined as {(e rsp (r h ), e rsp (r k )) E 2 r h k, mpcs(e rsp (r h ) : bc h, e rsp (r k ) : bc k ) s} where E r denotes the set of response events of read operations that occurred after r response. To concude the proof we need to find a H H EC and H H SC. Any H in which at east two read() operations return a bockchain sharing the same prefix but diverging in their suffix vioate the Strong prefix property, which concudes the proof. Let us remark that the BockTree aows at any time to create a new branch in the tree, which is caed a fork in the bockchain iterature. Moreover, an append is successfu ony if the input bock is vaid with respect to a predicate. This means that histories with no append operations are triviay admitted. In the foowing we wi introduce a new abstract data type caed Token Orace that when combined with the BockTree wi hep in (i) vaidating bocks and (ii) controing forks. We wi first formay introduce the Token Orace in Section 3.2 and then we wi define the properties on the BockTree augmented with the Token Orace in Section Token orace Θ-ADT In this section we formaize the Token Orace Θ to capture the creation of bocks in the BockTree structure. The bock creation process requires that the new bock must be cosey reated to an aready existing vaid bock in the BockTree structure. We abstract this impementation-dependent process by assuming that a process wi obtain the right to chain a new bock b to b h if it successfuy gains a token tkn h from the token orace Θ. Once obtained, the proposed bock b is considered as vaid, and wi be denoted by b tkn h. By construction b tkn h B. In the foowing, in order to be as much genera as possibe, we mode bocks as objects. More formay, when a process wants to access a generic object obj h, it invokes the gettoken(obj h, obj ) operation with object obj from set O = {obj 1, obj 2,... }. If gettoken(obj h, obj ) operation is successfu, it returns an object obj tkn h O, where (i) tkn h is the token required to access object obj h and (ii) each object obj k O is vaid with respect to predicate P, i.e. P (obj k ) =. We say that a token is generated each time it is provided to a process and it is consumed when the orace grants the right to connect it to the previous object. Each token can be consumed at most once. To consume a token we define the token consumption consumetoken(obj tkn h) operation, where the consumed token tkn h is the token required for the object obj h. A maxima number of tokens k for an object obj h is managed by the orace. The consumetoken(obj tkn h ) side-effect on the state is the insertion of the object obj tkn h in a set K h as ong as the cardinaity of such set is ess than k. In the foowing we specify two token oraces, which differ in the way tokens are managed. The first orace, caed prodiga and denoted by Θ P, has no upper bound on the number of tokens consumed for an object, whie the second orace Θ F, caed fruga, and denoted by Θ F, assures contros that no more than k token can be consumed for each object. Θ P when combined with the BockTree abstract data type wi ony hep in vaidating bocks, whie Θ F manages tokens in a more controed way to guarantee that no more than k forks can occur on a given bock. 11

12 3.2.1 Θ P -ADT and Θ F -ADT definitions For both oraces, when gettoken(obj k, obj h ) operation is invoked, the orace provides a token with a certain probabiity p αi > 0 where α i is a merit parameter characterizing the invoking process i. 2 Note that the orace knows α i of the invoking process i, which might be unknown to the process itsef. For each merit α i, the state of the token orace embeds an infinite tape where each ce of the tape contains either tkn or. Since each tape is identified by a specific α i and p αi, we assume that each tape contains a pseudorandom sequence of vaues in {tkn, } depending on α i. 3 When a gettoken(obj k, obj h ) operation is invoked by a process with merit α i, the orace pops the first ce from the tape associated to α i, and a token is provided to the process if that ce contains tkn. Both oraces aso enjoy an infinite array of sets, one for each object, which is popuated each time a token is consumed for a specific object. When the set cardinaity reaches k then no more tokens can be consumed for that object. For a sake of generaity, Θ P is defined as Θ F with k = whie for Θ F a predetermined k N is specified. K tape α1 tkn... {} 1 {} 2 {} 3 {} 4... obj 1 obj 2 obj 3 obj 4... tape α2 tkn tkn.... Figure 5: The Θ F abstract state. The infinite K array, where at the beginning each set is initiaized as empty and the infinite set of infinite tapes, one for each merit α i in A. We first introduce some definitions and notations. O = {obj 1, obj 2,... }, infinite set of generic objects uniquey identified by their index i; O O, the subset of objects vaid with respect to predicate P, i.e. obj i O, P (obj i ) =. T = {tkn 1, tkn 2,... } infinite set of tokens; A = {α 1, α 2,... } an infinite set of rationa vaues; M is a countabe not empty set of mapping functions m(α i ) that generate an infinite pseudo random tape tape αi such that the probabiity to have in a ce the string tkn is reated to a specific α i, m M : A {tkn, } ; K[ ] is a infinite array of sets (one per object) of eements in O. A the sets are initiaized as empty and can be fufied with at most k eements, where k N is a parameter of the orace ADT; pop : {tkn, } {tkn, }, pop(a w) = w; head : {tkn, } {tkn, }, head(a w) = a; 2 The merit parameter can refect for instance the hashing power of the invoking process. 3 We assume a pseudorandom sequence mosty indistinguishabe from a Bernoui sequence consisting of a finite or infinite number of independent random variabes X1, X2, X3,... such that (i) for each k, the vaue of X k is either tkn or ; and (ii) X k the probabiity that X k = tkn is p αi. 12

13 gettoken(obj 1, obj k )/obj tkn 1 k if pop(tape α1 ) = tkn consumetoken(obj tkn 1 k )/{obj tkn 1 k } if K[1] < k b tkn 1 k T ξ 0 ξ 1 ξ 2 K {obj tkn0 1 } {} {}... K {obj tkn0 1 } {} {}... K {obj tkn0 1 } {obj tkn1 k } {}... tapeα1 tkn... tapeα1... tapeα1... ξ 0 = { tapeα2 tkn...., k} ξ 1 = { tapeα2 tkn...., k} ξ 2 = { tapeα2 tkn...., k} Figure 6: A possibe path of the transition system defined by the Θ F and Θ P -ADTs. We use the foowing syntax on the edges: operation/output. add : {K} N O {K}, add(k, i, obj tkn h ) = K : K[i] = K[i] {obj tkn h } if K[i] < k; ese K[i] = K[i]; get : {K} N N, get(k, i) = K[i]; Definition 3.5. (Θ F -ADT Definition). The Θ F Abstract Data type is the 6-tupe Θ F -ADT = A= {gettoken(obj h, obj ), consumetoken(obj tkn h ) : obj h, obj tkn h O, obj O, tkn h T}, B= O Booean, Z= m(a) {K} k {pop, head, dec, get}, ξ 0, τ, δ, where the transition function τ : Z A Z is defined by τ(({tape α1,..., tape αi,... }, K, k), gettoken(obj h, obj )) = ({tape α1,..., pop(tape αi ),... }, K, k) with α i the merit of the invoking process; τ(({tape α1,..., tape αi,... }, K, k), consumetoken(obj tkn h )) = ({tape α1,..., tape αi,... }, add(k, h, obj tkn h )), if tkn h T ; {({tape α1,..., tape αi,... }, K, k)} otherwise. and the output function δ : Z A B is defined by δ(({tape α1,..., tape αi,... }, K, k), gettoken(obj h, obj )) = obj tkn h : obj tkn h O, tkn h T, if head(tape αi ) = tkn with α i the merit of the invoking process; otherwise; δ(({tape α1,..., tape αi,... }, K, k), consumetoken(obj tkn h )) = get(k, h). Definition 3.6. (Θ P -ADT Definition). The Θ P Abstract Data type is defined as the Θ F -ADT with k =. Figure 6 shows a possibe path of the transition system defined by the Θ F and Θ P -ADTs. 3.3 BT-ADT augmented with Θ Oraces In this section we augment the BT-ADT with Θ oraces and we anayze the histories generated by their combination. Specificay, we define a refinement of the append(b ) operation of the BT- ADT with the orace operations which triggers the gettoken(b h ast bock(f(bt)), b ) operation tkn as ong as it returns a token on b k, i.e., b h which is a vaid bock in B. Once obtained, the tkn token is consumed and the append terminates, i.e. the bock b h is appended to the bock h in 13

14 the bockchain f(bt) ({b 0 } f(bt) h {b }). Notice that those two operations and the concatenation occur atomicay. We say that the BT -ADT augmented with Θ F or Θ P orace is a refinement R(BT -ADT, Θ F ) or R(BT -ADT, Θ P ) respectivey. Let us define the foowing auxiiary function: evauate: B B Θ boo. evauate(b, δ b δ a )= true if ( h : b tkn h δ b ( X : b tkn h X X δ a)); fase otherwise. Definition 3.7. [R(BT -ADT, Θ F ) refinement] Given the BT-ADT= A, B, Z, ξ 0, τ, δ, and the Θ F - ADT =(A Θ, B Θ, Z Θ, ξ Θ 0, τ Θ, δ Θ ), we have R(BT ADT, Θ F )= A = A A Θ, B = B B Θ, Z = Z Z Θ, ξ 0 = ξ 0 ξ Θ 0, τ, δ, where the transition function τ : Z A Z is defined by τ a = τ (({tape α1,..., tape αi,... }, K, k, bt, f, P ), gettoken(b k ast bock(bt), b )) = ({tape α1,..., pop(tape αi ),... }, K, k, bt, f, P ); τ b = τ (({tape α1,..., tape αi,... }, K, k, bt, f, P ), consumetoken(b tkn h )) = ({tape α1,..., tape αi,... }, add(k, h, b tkn h ), k, {b 0 } f(bt) h {b }, f, P ) if tkn h T b tkn h get(k, ) ; ({tape α1,..., tape αi,... }, K, k, bt, f, P ) otherwise; τ (({tape α1,..., tape αi,... }, K, k, bt, f, P ), append(b)) = τ b τ a con- where τ b τa is the repeated appication of τ a unti δ a (({tape α1,..., tape αi,... }, K, k, bt, f, P ), gettoken(b k catenated with the τ b appication; ast bock(bt), b )) = b tkn h τ ({tape α1,..., tape αi,... }, K, k, bt, f, P ), read() = bt. and the output function δ : Z A B is defined by: δ a = δ (({tape α1,..., tape αi,... }, K, k, bt, f, P ), gettoken(b k ast bock(bt), b )) = b tkn h b tkn h B, tkn h T, if head(tape αi ) = tkn with α i the merit of the invoking process; otherwise; δ b = δ (({tape α1,..., tape αi,... }, K, k, bt, f, P ), consumetoken(obj tkn h )) = get(k, h); : δ (({tape α1,..., tape αi,... }, K, k, bt, f, P ), append(b)) = evauate(b, δ b δa), where δ b δa is the repeated appication of δ a unti δ a (({tape α1,..., tape αi,... }, K, k, bt, f, P ), gettoken(ast bock(bt), b)) = concatenated with the δ b appication; b tkn h δ (({tape α1,..., tape αi,... }, K, k, bt, f, P ), read()) = {b 0 } f(bt); δ (({tape α1,..., tape αi,... }, K, kbt 0, f, P ), read()) = b 0. Definition 3.8 (R(BT -ADT, Θ P ) refinement). Same definition as the R(BT -ADT, Θ F ) refinement. Definition 3.9 (k-fork Coherence). A concurrent history H = Σ, E, Λ,,, of the BT-ADT composed with Θ F -ADT satisfies the k-fork Coherence if there are at most k append() operations that return for the same token. 14

15 append(b 1)/true if b 1 B read()/b 0 b1 append(b 2)/true if b 2 B read()/b 0 b 1 b2 append(b 3)/fase append(b 4)/ ξ 0 ξ 1 ξ 2 if b 3 / B if b 4 / B ξ 0 = { b0, f, P } ξ 1 = { b0 b1, f, P } ξ 2 = { b0 b1 b2, f, P } gettoken(b 0 ast bock(f(bt)), b 1 )/b tkn 0 1 if pop(tape α1 ) = tkn consumetoken(b tkn 0 1 )/{b tkn 0 1 } if K[1] < k b tkn 0 1 T ξ 0 ξ 1/a ξ 1/b K {} {}... {} {}... {b tkn0 1 } {}... tapeα1 tkn { tapeα2 tkn....,k, b 0, f, P } { tkn.... b,k, 0, f, P }{ tkn....,k, b 0 b 1, f, P } Figure 7: Refinement of the append() operation. We use the foowing syntax on the edges: operation/output. Theorem 3.2 (k-fork Coherence). Each concurrent history H = Σ, E, Λ,,, of the BT- ADT composed with a Θ F -ADT satisfies the k-fork Coherence. Proof. We prove the theorem by considering the defined refinement (Definition 3.7) where (i) there are a infinite number of gettoken() invocations for object obj and (ii) given a vaid bock as input parameter, the consumetoken() operation successfuy terminates if it has been invoked ess than k times for the same token. From the properties of the pseudo random sequences of tapes, if there are an infinite number of gettoken() invocations for object obj then there exists at east one response for which gettoken() operation returns a token t, which, when passed as input of the consumetoken() operation it successfuy terminates if at most k 1 tokens t have been aready consumed. Let us notice, the Θ F -ADT guarantees by construction the safety property (Theorem 3.2). Liveness properties (i.e., the Termination) for Θ F -ADT and Θ P -ADT depend on the communication mode and faiure mode in which those are impemented. 3.4 Hierarchy In this section we define a hierarchy between different BT-ADT satisfying different consistency criteria when augmented with different orace ADT. We use the foowing notation: BT-ADT SC and BT-ADT EC to refer respectivey to BT-ADT generating concurrent histories that satisfies the SC and the EC consistency criteria. When augmented with the oraces we have the foowing four typoogies, where for the fruga orace we expicit the vaue of k: R(BT-ADT SC, Θ F,k ), R(BT-ADT SC, Θ P ), R(BT-ADT EC, Θ P ), R(BT-ADT EC, Θ F,k ). In the foowing we want study the reationship among the different refinements. Without oss of generaity, et us consider ony the set of histories ĤR(BT-ADT,Θ) such that each history 15

16 R(BT-ADT SC, Θ F,k=1 ) Theorem 3.4 Theorem 3.3 R(BT-ADT SC, Θ F,k>1 ) Coroary R(BT-ADT EC, Θ F,k>1 ) Theorem 3.3 R(BT-ADT SC, Θ P ) Coroary R(BT-ADT EC, Θ P ) Figure 8: R(BT-ADT, Θ) Hierarchy. Ĥ R(BT-ADT,Θ) ĤR(BT ADT,Θ) is purged from the unsuccessfu append() response events (i.e., such that the returned vaue is ). Let ĤR(BT-ADT,Θ F,k) be the concurrent set of histories generated by a BT-ADT refined with Θ F,k -ADT and et ĤR(BT-ADT,Θ P ) be the concurrent set of histories generated by a BT-ADT refined with Θ P -ADT. Theorem 3.3. Ĥ R(BT-ADT,Θ F ) ĤR(BT-ADT,Θ P ). Proof. The proof foows from Theorem 3.2 considering that R(BT, Θ P ) can generate histories with an infinite number of append() operations that successfuy terminate whie R(BT, Θ F ) can generate history with at most k append() operations that successfuy terminate. Theorem 3.4. If k 1 k 2 then ĤR(BT-ADT,Θ F,k 1 ) ĤR(BT-ADT,Θ F,k 2 ). Proof. The proof foows from Theorem 3.2 appying the same reasoning as for the proof of Theorem 3.3 with k 1 k 2. Finay, from Theorem 3.1 the next coroary foows. Coroary Ĥ (R(BT-ADT SC,Θ) ĤR(BT-ADT EC,Θ). Combining Theorem 3.1 and Theorem 3.3 we obtain the hierarchy depicted in Figure 8. 4 Impementing BT-ADTs 4.1 Impementabiity in a concurrent mode In this Section we show that Θ F,k=1 has consensus number and that Θ P has consensus number 1. We consider a concurrent system composed by n processes such that up to f processes are fauty (stop prematurey by crashing), f < n. Moreover, processes can communicate through atomic registers. 16

17 (1) consumetoken(b tkn h ) : (2) previous vaue K[h]; (3) if (previous vaue == {} tkn h T)then; (4) K[h] K[h] {b tkn h }; (5) endif (6) return K[h] (1) compare&swap(register, od vaue, new vaue) : (2) previous vaue register; (3) if (previous vaue == od vaue)then; (4) register new vaue; (5) endif (6) return previous vaue Figure 9: Compare&Swap() and consumetoken() in the case of Θ F,k= Fruga with k = 1 at east as strong as Consensus In the foowing we prove that there exists a wait-free impementation of the Consensus [24] by the Θ F,k=1 Orace object. In particuar, in this case Θ F,k=1 = A= {gettoken(b h, b ), consumetoken(b tkn h ) : b h, b tkn h B, b B, tkn h T}, B= B Booean, Z= m(a) {K} k {pop, head, dec, get}, ξ 0, τ, δ. We expicit consider bocks and vaid bocks (B and B ) rather than objects and vaid objects (O and O ). Moreover, we consider a version of the Consensus probem for the bockchain. Thus, we consider the Vaidity property as in [11] such that the decided bock b satisfies the predicate P. Definition 4.1. Consensus C: Termination. Every correct process eventuay decides some vaue. Integrity. No correct process decides twice. Agreement. If there is a correct process that decides a vaue b, then eventuay a the correct processes decide b. Vaidity[11]. A decided vaue is vaid, it satisfies the predefined predicate denoted P. To this aim, we first prove that there exists a wait-free impementation of Compare&Swap() object by consumetoken() object in the case of Θ F,k=1, impying that consumetoken() has the same Consensus number as Compare&Swap() which is (see [20]). Finay we compose the consumetoken() with the gettoken() object proving that there exist a wait-free impementation of C by Θ F,k=1. Figure 9 describes consumetoken() (CT), as specified by the Θ-ADT, aong with the Compare&Swap() (CAS). Compare&Swap() takes three parameters as input, the register, the od vaue and the new vaue. If the vaue in register is the same as od vaue then the new vaue is stored in register and in any case the operation returns the vaue that was in register at the beginning of the operation. In comparison with consumetoken(b tkn h ) we have that b tkn h is the new vaue, register is K[h] and the impicit od vaue is {}. That is, add(k, h, b) stores b in K[h] if K[h] < k = 1, then if K[h] = {}. In any case the operation returns the content of K[h] at the end of the operation itsef. Figure 10 describes and agorithm that reduces CAS to consumetoken(). Theorem 4.1. If input vaues are in B then there exists an impementation of CAS by CT in the case of Θ F,k=1. Proof. The proof simpy foows by construction. Let us consider the agorithm in Figure 10. When the Compare&Swap() operation is invoked, if K[h] is empty, then when consumetoken() is invoked 17

18 (1) compare&swap(k[h], {}, b tkn h ) : (2) returned vaue consumetoken(b tkn h ); (3) if (returned vaue == b tkn h )then; (4) return {}; (5) ese return returned vaue; (6) endif Figure 10: An impementation of CAS by CT in the case of Θ F,k=1. upon event propose(b): (1) vaidbock ; (2) vaidbockset ; % since k = 1 then it contains ony one eement. (3) whie (vaidbock = ): (4) vaidbock gettoken(b 0, b); (5) vaidbockset consumetoken(vaidbock); % it can be different from vaidbock (6) trigger decide(vaidbockset); Figure 11: The Protoco A that reduces the Consensus probem to the Fruga Orace with k = 1. with b tkn h (vaid by hypothesis) K[h] is popuated with b tkn h. Such vaue is ater returned by the consumetoken() operation in retuend vaue. Since it is the same vaue as b tkn h (ine 3) then the Compare&Swap returns the vaue of K[h] at the beginning of the operation, {}. If the condition at ine (ine 3) does not hod, then this means that K[h] did not change during the operation and its vaue, in returned vaue is returned. Figure 11 describes a simpe impementation of Consensus by Θ F,k=1. When a correct process p i invokes the propose(b) operation it oops invoking the gettoken(b 0, b) operation as ong as a vaid bock is returned (ines 3-4). In this case the gettoken() operation takes as input some bock b 0 and the proposed bock b. Afterwards, when the vaid bock has been obtained p i invokes the consumetoken(vaidbock) operation whose resut in stored in the tokenset variabe (ine 5). Notice, the first process that invokes such operation is abe to successfuy consume the token, i.e., the vaid bock is in the Orace set corresponding to b 0, which cardinaity is k = 1, and such set is returned each time the consumetoken() operation is invoked for a bock reated to b 0. Finay, (ine 6) the decision is triggered on such set (with contains one eement). Theorem 4.2. Θ F,k=1 Orace has Consensus number. Proof. The proof proceeds by construction, et us consider the impementation in Figure 11. A correct processes performing the Consensus are ooping on the gettoken(b 0, b) operation. From the properties of the pseudo random sequences of tapes, if there are an infinite number of gettoken() invocations for an bock b 0 then there exists at east one response for which gettoken() operation returns a vaid bock b tkn 0. Thus, a correct process i can invoke the consumetoken(b tkn 0 ) operation with vaid vaues. Since a the processes invoke such operation with vaid vaues with can appy Theorem 4.1 which concudes the proof considering that CAS has Consensus number ([20]). 18

19 (1) consumetoken k (tkn) : (2) R h,m update(r h,m, tkn m) (3) returned vaue scan(r h,1, R h,2,..., R h,m,... R h,n ) (4) return returned vaue; Figure 12: An impementation of CT by Atomic Snapshot in the case of Θ P Prodiga not stronger than an Atomic Register In order to show that the Prodiga orace Θ P has consensus number 1, it suffices to find a wait-free impementation of the orace by an object with consensus number 1. To this end we present a straightforward impementation of the Prodiga orace by Atomic Snapshot[7]. Let us firsty simpify the notation of the consume token operation. Let us consider a consume token invoked for a given bock b h, denoted as consumetoken h (tkn m ), which simpy writes a token from the set T = {tkn 1, tkn 2,..., tkn m,... } in the set K[h]. Without oss of generaity et us assume that: (i) tokens are uniquey identified, (ii) cardinaity of T is n finite but not known and (iii) the set K[h] is represented by a coection of n atomic registers K[h = {R h,1, R h,2,..., R h,m,... R h,n }, where R h,m is assigned to the tkn m token, i.e. R h,m can contain either or tkn m. It can be observed that the consumetoken h (tkn m ) in the case of k infinite, aways aows to write the token tkn m in R h,m, i.e. there aways exists a register R h,m for the proposed token tkn m. By the orace definition, moreover, the consumetoken h (tkn m ) returns a read of the n registers that incudes the ast written token. Figure 12 shows a trivia impementation of commit token CT using Atomic Snapshot that offers update(r i, vaue), scan(r 1, R 2,..., R n ) operation to update a particuar register and perform an atomic read of input registers, respectivey. Theorem 4.3. Θ P Orace has Consensus number 1. Proof. The proof triviay foows from impementation in Figure 12 of the consensus token operation of the Prodiga orace by the Atomic Snaposhot object and from [7]. 4.2 Impementabiity in a message-passing system mode We consider a message-passing system composed of an arbitrary arge but finite set of n processes, Π = {p 1,..., p n }. The passage of time is measured by a fictiona goba cock (e.g., that spans the set of natura integers). Processes in the system do not have access to the fictiona goba time. Each process of the distributed system executes a singe instance of a distributed protoco P composed of a set of agorithms, i.e., each process is running an agorithm. Processes can exhibit a Byzantine behavior (i.e., they can arbitrariy deviate from the protoco P they are supposed to run). A process affected by a Byzantine behavior is said to be fauty, otherwise we refer to such process as non-fauty or correct. We make no assumption on the number of faiures that can occur during the system execution. Processes communicate by exchanging messages via communication channes. We say that a communication channes are asynchronous if the is no upper bound on the message deivery deay. Contrariy, communication channes are synchronous if messages sent by correct processes at time t are deivered by correct processes by time t + δ. Finay, communication channes are weaky synchronous if there exist an unknown a priori time τ after which the communication channes behave as synchronous. We specify time to time the channes synchrony assumption considered, when eft untod we consider asynchronous channes. 19

20 The BockTree being now a shared object repicated at each process, we note by bt i the oca copy of the BockTree maintained at process i. To maintain the repicated object we consider histories made of events reated to the read and append operations on the shared object, i.e. the send and receive operations for process communications and the update operation for BockTree updates. We aso use subscript i to indicate that the operation occurred at process i: update i (b g, b i ) indicates that i inserts its ocay generated vaid bock b i in bt i with b g as a predecessor. Updates are communicated through send and receive operations. An update reated to a bock b i generated on a process p i, sent through send i (b g, b i ), and received through a receive j (b g, b i ), takes effect on the oca repica bt j of p j with the operation update j (b g, b i ). We assume a generic impementation of the update operation: when process i ocay updates its BockTree bt i with the vaid bock b i (returned from the consumetoken() operation), we write update i (b, b i ). When a process j execute the receive j (b, b i ) operation, it ocay updates its BockTree bt j by invoking the update j (b, b i ) operation. In the remaining part of the work we consider impementations of BT-ADT in a Byzantine faiure mode where the set of events is restricted as foows. Definition 4.2. The execution of the system that uses the BT-ADT =(A, B, Z, ξ 0, τ, δ) in a Byzantine faiure mode defines the concurrent history H = Σ, E, Λ,,, (see Definition 2.4) where we restrict E to a countabe set of events that contains (i) a the BT-ADT read() operations invocation events by the correct processes, (ii) a BT-ADT read() operations response events at the correct processes, (iii) a append(b) operations invocation events such that b satisfies the predicate P and, (iv) send, receive and update events generated at correct processes. In this Section we consider a message passing system mode and we show the impossibiity to achieve Strong Prefix without Consensus and impossibiity to achieve Eventua Prefix if at east one message sent by a correct process is ost. 4.3 Communication Abstractions We now define the properties that each history H generated by a BT-ADT satisfying the Eventua Prefix Property has to satisfy and then we prove their necessity. Definition 4.3 (Update Agreement). A concurrent history H = Σ, E, Λ,,, of the system that uses a BT-ADT satisfies the Update Agreement if satisfies the foowing properties: R1. update i (b g, b i ) H, send i (b g, b i ) H; R2. update i (b g, b j ) H, receive i (b g, b j ) H such that receive i (b g, b j ) update i (b g, b j ); R3. update i (b g, b j ) H, receive k (b g, b j ) H, k. Figure 13 depicts a concurrent history that satisfies the Update Agreement properties. In the foowing, for ease of notation we consider that the seection function f F returns directy aso the genesis bock. Lemma 4.4. Property R1 or Property R2 are necessary conditions for any protoco P to impement a BT-ADT generating histories H satisfying the Eventua Prefix property. 20