Cob: a Leaderless Protocol for Parallel Byzantine Agreement in Incomplete Networks

In this paper we extend the \emph{Multidimensional Byzantine Agreement (MBA) Protocol}, a {leaderless} Byzantine agreement for lists of arbitrary values, into a protocol suitable for wide gossiping networks: \emph{Cob}. This generalization allows the consensus process to be run by an incomplete network of nodes provided with (non-synchronized) same-speed clocks. Not all nodes are active in every step, so the network size does not hamper the efficiency, as long as the gossiping broadcast delivers the messages to every node in reasonable time. These network assumptions model more closely real-life communication channels, so the Cob protocol may be applicable to a variety of practical problems, such as blockchain platforms implementing sharding. Cob has the same Bernoulli-like distribution that upper-bounds the number of steps as the MBA protocol. We prove its correctness and security assuming a supermajority of honest nodes in the network, and compare its performance with Algorand.


Introduction
One of the main issues that blockchain platforms must deal with is the lack of scalability.Scalability is the ability of a platform to grow and manage an increasing number of requests.In particular, we say that a blockchain scales if it can easily adapt to changes in the number of users that decide to join in, as well as in the number of transaction requests that such users broadcast to the nodes maintaining the blockchain platform.In order to solve the scalability issues of blockchain platforms, many approaches have been proposed over the years.Some of them are the block size increase, the use of off-chain state channels, segregated witness (SegWit) and sharding.Among the proposed approaches, sharding seems to be the most promising [16].
The term sharding comes from database management, where it identifies a particular type of database partitioning, that consist in dividing large databases into smaller parts, called shards.Shards are more manageable in terms of server hosting and other aspects of database maintenance, and allow to have faster query time by diversifying the responsibility of a database structure.
In the context of blockchain design, sharding consists in breaking the blockchain into small parts that are managed in parallel by node subsets, called shards.This augments throughput, since many transactions can be simultaneously validated, allowing blockchains to effectively scale for a huge number of users.Many blockchain platforms use sharding as a mean to reach scalability, for example Ethereum 2.0 [2], Zilliqa [23] or EOS [14].For a better description of blockchain sharding we refer to the survey of Meneghetti et al. [16].Together with the security concerns regarding how to distribute the nodes among different shards (so that groups of cooperating malicious nodes are not assigned to the same shard), one of the main issues the protocol designer must deal with is the way the transactions validated by different shards can reach compatibility with one another.This problem is also referred to as reconciliation problem.
Since blockchains are distributed ledgers, one of the core component is represented by the consensus protocol that the blockchain network must execute.The consensus protocol allows the nodes of the network to update their copy of the ledger in the very same way.Therefore, a blockchain implementing sharding must be able to bring the network to agreement (reach consensus) on which blocks are legitimately created by each shard, so that the network can proceed with the reconciliation of such transactions.One possible way to achieve this goal is to let the network execute a consensus protocol and decide which shards legitimately produced a valid block.

Cob Protocol
In this paper we present Cob, a novel consensus protocol which efficiently solves the problem of reaching consensus on a set of blocks legitimately created by each shard.In particular we propose a viable solution for permissionless blockchain networks.
This problem can be easily extended to the following more general problem: Problem 1.1 Given a set of events which a network of nodes can observe, how can the nodes reach consensus on some relevant information about such events?
In the context of blockchains implementing sharding the events to be observed are the creation and diffusion of a block by each shard; the relevant information about the event is the content of the block or some data which identifies it (e.g. the digest of the block computed via an hash function).In this paper we will describe Cob following the more general problem (i.e.Problem 1.1), however, the reader can keep in mind the specific application of reaching consensus over the shards.
Given a set of m events the nodes can observe, an instance of Cob requires every node in the network to build a list with m components.Each event (e.g.creation of a block of a shard) is associated to a component of the list and, once the nodes observe an event, they locally record in the corresponding component the relevant information about such event (e.g. the digest of the newly created block).This can be referred to as the observation phase.
After the observation phase, the nodes of the network will continue with a Cob protocol execution, exchanging messages until they reach consensus on a list of relevant information.

Cob: a Parallel Consensus Protocol
We say that Cob is a parallel protocol since it is designed in a way that the consensus process is carried out simultaneously on each component of the list by every node involved in the consensus protocol.Every message broadcast by the nodes contains some information about each component, but the consensus achievement on each component is independent from the others.
In particular the nodes will exchange lists of values during the whole protocol execution.In the first 3 steps they will exchange lists of strings (the relevant information) and in the following steps they will exchange lists of bits in order to reduce the bandwidth required.
Agreement might be reached faster in some components, however the nodes will stop the protocol execution only when they realize that they agree on every component, therefore on the whole list.
If an event is not detected (e.g. a shard did not broadcast any block) or it is impossible to reach consensus (e.g.multiple blocks have been broadcast by the same shard), agreement will be reached on the special value ⊥.
It is crucial that agreement is carried out in parallel on the list components instead of on the whole list, otherwise a widespread disagreement on a single component would affect the consensus achievement on the other components as well.Conversely, if agreement is carried out in parallel and independently, it is possible to preserve and finalize the agreed upon components, and to set to ⊥ the controversial components.

Cob: a Leaderless Consensus Protocol
Since in permissionless blockchain networks anyone can join the network, we must consider an attacker that may try to disrupt the consensus process in several ways.For example, if we stick to the example of the blockchain implementing sharding, when an attacker shares with the network the list built during the observation phase, it may broadcast different lists to different nodes, advertising different blocks related to the same shard.This would cause a network partition in groups with different views about what the attacker has seen.Another attack it may perform is a censorship attack, pretending not to have received a block by a specific shard, setting the related component to ⊥.
Many classical consensus protocols used by blockchain networks to record transactions [20,24,7,23,15] (e.g.cryptocurrency transfers, smart contract execution requests) do not guarantee that a specific transaction will be included into the blockchain as soon as it is broadcast, in the newly created block.In many cases this is just fine, in fact the transaction can be included into one of the following blocks after waiting a reasonable time interval.
For this reason, many consensus protocols are leader based, which means that there is a node which proposes a new block, and then the network decides whether to accept it or not.If the network decides to discard the leader proposal it elects a new leader and starts over.However, it is essential that the leader must change from time to time so that, if an attacker tries to undermine the liveness of the platform or to practice censorship, a (eventually honest) new leader will propose a new block (in one case), or will include the deliberately excluded transactions (in the other case).
The Problem 1.1 differs from the problem of (eventually) recording transaction requests.The events observed by the network must be discussed right after they are observed and the relevant information must be included in the agreed upon list or excluded once and for all.
Therefore, it is essential for our consensus protocol to be leaderless.In fact, a leader, if honest, would propose a list of relevant information which is heavily influenced by their own point of view (which in some cases might lead them to take incorrect decisions), and if the leader is malicious may easily perform censorship attacks refusing to include some information in the list, or deliberately include invalid information.In both cases, if the network does not agree even with one component proposed by the leader, it will reject the leader proposal, and this process is repeated until a leader proposes a list which gets accepted by a majority of the network.Note that this might not even happen, in fact, if there is a wide disagreement among the nodes about one or more components, there might not exist a list which is accepted by such majority.
So we have shown that there are many reasons that suggest to abandon the leader-based approach in favour of a leaderless approach.A leaderless consensus protocol, instead of questioning a single node, requires several nodes to share their own proposal.Then, based on these proposals, the protocol will bring the network to a consensus on a shared output as we will show in Section 3.2 and prove in Section 4.
We will show in Section 3.2 that in the first step of Cob, a set of randomly chosen nodes will share with the network their observed values, namely the list of relevant information (e.g. the hash of the shard blocks they have received).Starting from this information, the network will carry on with the consensus protocol to decide which components of the list can have a value, since the nodes of the network agree on some relevant information, and which will be set to ⊥.

State of the Art and Considerations
In [10] is presented the MBA Protocol, a solution to Problem 1.1 for a relatively small network of a fixed number n of nodes, under some strong communication assumptions, and under the threat of an attacker that controls less than 1  3 of the nodes.In particular is assumed a strongly synchronous communication model and a complete network, where every node could instantaneously send a message to each other.These assumption are unrealistic or dramatically reduce the possible application contexts.
In this paper we go a step further and define an analogous protocol called Cob, which works under more realistic assumptions and can be executed by a network of nodes of any size and the nodes communicate gossiping the messages broadcast in the network.This model makes Cob a viable solution to Problem 1.1 for a permissionless blockchain platform network.In fact, as we will see in Section 2.1, every step of the protocol is executed by a randomly selected set of nodes, whose cardinality is constant in expected value: this guarantees that, independently of the size of the network, the number of messages broadcast during each step will be constant.
As we have stated in Section 1.1.2,we are interested in leaderless consensus protocols which work under realistic network and communication assumptions.
There is no doubt that asynchronous BFT protocols would be the best solution for building high-assurance and resistant consensus protocols.Unlike synchronous or weakly synchronous protocols, whose liveness relies on communication assumptions, the asynchronous protocols do not put their liveness at risk.
In 2016, Miller et al. presented the leaderless asynchronous BFT protocol HoneyBadgerBFT [18], which significantly improved prior asynchronous BFT protocols [1,3,4].HoneyBadgerBFT is based on Asynchronous Common Subset (ACS) [1] implemented in combination with the asynchronous binary consensus protocol of Mostéfaoui et al. [19].HoneyBadgerBFT can be used as consensus protocol for blockchains, achieving a throughput of 200 KB/s of data appended to the ledger using 10 MB blocks (therefore it requires 5 minutes for each protocol run) using 104 participating servers.Later, in 2018, Duan et al. improved the HoneyBadgerBFT protocol presenting BEAT [8], a family of five asynchronous consensus protocols designed to meet different goals, such as different performance metrics (scalability, bandwidth or latency).Another improvement to HoneyBadgerBFT was proposed by Guo et al. with the Dumbo protocol [12].
However, these leaderless asynchronous BFT protocols have performance (latency, throughput) issues when they are executed by a number of replicas which exceeds the hundreds.For this reason, these protocols, or their variations, could be adopted only by permissioned or private blockchain platforms, because they are often controlled by relatively few nodes, but they do not provide a viable solution to the consensus problem in the context of permissionless networks.Moreover, these protocols must be executed by a fixed set of nodes who actively partake to the communication protocol.Therefore, these protocols can be incapable to guarantee resistance to targeted attacks that either compromise the servers involved or disconnect them from the network.
Since in this paper we are interested in solving a problem which can be applied to permissionless blockchain platforms implementing sharding, we assume that the number of nodes in the network can grow with no limit (potentially reaching millions of nodes) still guaranteeing the highest level of decentralization.
Therefore the asynchronous protocols mentioned above, classical primarybackup protocols such as PBFT [6] and other recent concurrent protocols such as Mir-BFT [22] or RCC [13] must be considered impractical for our use case due to the reduced and fixed number of actors involved in the protocol execution.
For this reason we must make some compromises, and find a solution which allows the implementation of a scalable platform settling for a protocol which relies on assumptions that are as weak as possible.
In this regard, Algorand [7] is a blockchain platform for cryptocurrency which adopts a BFT consensus protocol that faces three main challenges: 1. avoid Sybil attacks: this is done using weighted users.Every user is weighted based on the amount of money in their account, therefore as long as more than 2 3 of the money is in honest hands, then the protocol is proven to be secure.
2. can scale to millions of users: this is achieved by choosing for every step a different committee, a small set of representative randomly selected from the set of users based on the users' weight.3. resists to denial of service attacks or disconnection of users performed by an attacker: in fact, relying on a committee which performs the operations, gives the possibility of targeted attacks against the chosen committee members.To prevent this, the protocol selects the committee members in a private and non interactive way via a verifiable random function (VRF) on the users' private key and some public data from the blockchain, a technique pioneered by Rabin in [21] which simulates a random lottery.
Once a player realizes they are selected in a committee then they must broadcast a message containing, among other things, the proof of their selection.At this point the attacker clearly knows about the selection and can try to corrupt such player.However, the nodes executing the protocol randomly change at every step and the attacker can not know in advance which node will be selected to broadcast a new message.This property is called player replaceability and protects the network from targeted attacks.
All these properties are achieved assuming that the attacker can corrupt or take control of any user in the network but, as we mentioned before, more than 2  3 of the money (on which each user's weight is based) must always be in honest hands.
Algorand, to guarantee liveness, makes a strong synchrony assumption [11] requiring that almost every honest node (e.g.95%), when it broadcasts a message, reaches almost every other honest node (e.g.95%) within a predetermined time interval.The time is measured by each node by using same speed clocks which might not be synchronized (pointing to different times) as long as they have the same speed.
Moreover, to guarantee safety a weak synchrony assumption is used: the network can be asynchronous (i.e.controlled by an adversary) for a long period of time, as long as this time is bounded (e.g. 1 day, 1 week).After that the network must be synchronous for a reasonably long period of time (e.g.few hours, 1 day) in order to ensure safety [11].
In this paper we build on top of Algorand's network and communication model a consensus protocol which solves the problem of reaching consensus on a list of relevant information about some observed events.In fact, for our scope, it is essential to involve a high number of nodes to safely determine that this information has been correctly recorded, so we cannot rely on asynchronous protocols (due to their limitations) and must compromise on the network assumptions.
Outline In Section 2 we establish the preliminaries necessary to describe Cob.We define our network assumptions, we recall some useful notation, then we describe the sortition mechanism that selects which nodes are active in each step of the protocol, giving the necessary definitions.Finally we describe our assumptions on the honesty of the nodes.
In Section 3 we introduce the actual protocol, presenting a reference list of all the parameters and then describing in detail every step.
Then, in Section 4 we formally analyze the properties of Cob, proving that it is a Byzantine agreement through a series of preparatory lemmas and propositions.The main theorem also gives a probabilistic upper bound on the number of steps that are necessary to halt the execution.
In Section 5 we analyze the message complexity and the weight of the data broadcast in the network in each protocol execution.We also compare the performance of Cob with the one of Algorand's consensus protocol [7] in solving Problem 1.1 in the context of blockchain platforms implementing sharding.
Finally in Section 6 we draw some conclusions and remarks, and outline future works to improve the applicability of the protocol.

Preliminaries
In this section we define some assumptions, preliminary concepts, and notations that will be used later on to describe Cob and prove its properties.

Network Assumptions
In complete networks, the number of messages exchanged through the network grows exponentially with the number of network participants, so for practical applications it is more convenient to consider a different network model, such as the Asynchronous Gossiping Network (AG networks) 1 presented by Micali in Algorand [7].
In this model messages are broadcast in the network in a gossiping fashion: a procedure characteristic of peer-to-peer communications where messages pass from one node to its neighbours and so on until they reach every node.
In gossiping networks we rely on each member to pass messages along to its neighbours, therefore it is reasonable to envisage the network as an incomplete, connected and non-directed graph.We assume that a message sent by an honest node reaches every honest node within a time limit that depends on the size of the message itself.Since malicious nodes can behave arbitrarily, this assumption means that malicious nodes cannot be cut vertices in the network graph, that is the graph remains connected even without the edges connected 1 Algorand describes the environment in which is defined as asynchronous.This is because the communications between nodes happen via gossip and the protocol steps, which for a single user are non-overlapping time intervals, for different users may overlap due to asynchrony.However, since Algorand assumes that exists a predetermined upper-bound to the time required by a message to reach (almost) every node, and therefore exists an upperbound to the delay between different nodes, Algorand can not be considered an asynchronous protocol.
to malicious nodes.We will also require that the ratio of malicious or faulty nodes is less than 1  3 .In an AG network there does not exist a common clock, but we assume that all network participants are provided with Same-Speed Clocks [7].In other words, we assume that each network participant has its own clock and that the clocks all have the same speed, even if they are not synchronized in any other way.
We take as time frame reference the earliest clock in the network, and suppose that the protocol execution starts at time 0, i.e. time starts when the first player begins the protocol execution.Moreover we assume that the discrepancy between any two clocks is at most a constant λ, that also upper bounds the time required to diffuse a "short" message of the protocol to the whole network (see Section 3.1), so each player will start the execution of the protocol at a time comprised in the interval [0, λ].For example, this discrepancy could be observed in a scenario in which the first player triggers the start of the protocol execution, broadcasting a signal and resetting its clock, and then each player starts the execution (and resets its clock) when it receives this signal, with the network delay causing the discrepancies.Afterwards the time discrepancies do not vary because of the same-speed nature of the clocks.

A Cryptographic Sortition Mechanism
In the protocol described in Section 3.2 not every player in the network is always active (i.e.authorized to broadcast messages), on the contrary at every step some players are selected to be active, while the others have a passive role.In order to better clear up this distinction, from now on in a specific step we will call players only the nodes selected to be active and broadcast their message, while a generic node of the network will be referred as a user.We will denote with P (s) the set of players of step s.
We want this selection to be random, and furthermore we would like it to be private and performed without the aid of a trusted third party.With private we mean that each user should be able to privately check if it will be selected to be active (i.e. a player) in a step, and then be able to prove its selection to the other players.This concept is closely related to that of verifiable random functions (VRF), i.e. pseudo-random functions which provide publicly verifiable proofs of their outputs' correctness.
In our protocol the sortition is implemented through a cryptographic hash function H (modeled as a random oracle) and a digital signature scheme (G, S, V ) with the uniqueness property, which is defined as follows.
Definition 2.1 (Digital Signature Scheme with Unique Signature) A digital signature scheme with unique signature is a triple of algorithms (G, S, V ) such that: -G is the key generation algorithm that outputs a secret key sk and a public key pk; -S is the signing algorithm, that given a message m and a private key sk outputs a signature σ = S (sk, m); -V is the verification algorithm that given a message m, a signature σ and a public key pk outputs either true or false, and such that: the scheme is correct, i.e. for every (sk, pk) generated with G it holds V (pk, S (sk, m) , m) = true ∀m ; the signature is unique, i.e. for any probabilistic polynomial time algorithm F that given a message outputs a public key pk and two distinct signatures σ = σ, we have that: where ε is negligible.Note that this property holds also for public keys whose relative private key is known, and even for values pk that are not legitimately generated public keys.
Given this definition, we can now describe the sortition of the active players in each step of the protocol.Definition 2.2 (Sortition Mechanism) Let (G, S, V ) be a digital signature scheme with unique signature, and suppose that every user 1 ≤ i ≤ N is identified by a public key pk i , let r be a random string independent from pk i for every 1 ≤ i ≤ N , and suppose that every user knows r and {pk i } 1≤i≤N .Moreover let n ≤ N be the desired number of players during each step s of the protocol, let H : {0, 1} * −→ {0, 1} d be a hash function, and let φ : {0, 1} d −→ (0, 1] be the standard decoding of a bit string into the unit interval φ (h) = . User i is selected to be a player during step s of the protocol, i.e. i ∈ P (s) , if: i , H (r s) = true .

Where σ (s) i
= S (sk i , s r).The signature σ (s) i can then be used to prove that i ∈ P (s) .Note that, when H is modeled as a random oracle, φ H σ (s) i is uniformly distributed, so the probability of a player to be selected is n N , and the expected number of active players is indeed n.
Note that the same sortition mechanism can be implemented with a weaker notion of signature scheme that allows signing failures.That is, a scheme where the output of S is a special symbol ⊥ with fixed probability f (supposing the message to be uniform in {0, 1} d ), with V (pk, ⊥, m) = false for every pk and m.The sole adjustment required is to increase the threshold n N to account for the signing failure, using n N (1−f ) instead.In some applications it might be desirable that players are selected with nonuniform probability.There is a simple trick to adjust the selection probability for each player: let p ∈ (0, 1] be a fixed probability and t i ≥ 1 be a publicly known threshold for player i.The tweaked process selects player i if it can provide a pair signature-counter σ i , H (r s c i ) = true, and c i ≤ t i .In other words the player i has t i attempts to produce a winning signature, so its probability to be selected is 1

Sortition Assumptions
Similarly to the MBA protocol [10], Cob requires that the number of honest nodes at each step s is more than two times the number of malicious players active at step s.Since the active players are randomly selected, we require that at each step there are enough active honest players with high probability.
We now define a probabilistic concept which will be widely used throughout this paper.Definition 2.3 We will write that an event E happens with overwhelming probability if P (E) ≥ 1 − , where ∈ (0, 1) is a parameter sufficiently close to 0.
A good choice for practical applications could be = 10 −12 .Definition 2.4 Let n be the expected number of active players in a step, we define the threshold t H = 2n 3 + 1.For every step s we choose the parameter n in a way that the following relationships between the number of honest players HP (s) and the number of malicious players MP (s) hold with overwhelming probability: Note that these two conditions imply that HP (s) > 2MP (s) .In practice, they imply that with overwhelming probability: the protocol has, at each step, the required 2  3 honest majority of players.at every step there is a sufficient number of honest players who can certify a new list or finalize a list component; two distinct nodes can not finalize the same component with two distinct values.
Note that the closer to 1 the ratio of honest users in the network is, the smaller the number of players for each step needs to be.
The parameter choice necessary to meet the requirements is done using variants of Chernoff bounds, as in Algorand [7] and the analysis of such bound can be found in [5].

Notation
We will typeset lists in boldface and in general subscript will be used to denote the player who created the value and the index of list components, while superscripts will refer to the protocol step in which the value has been produced.So v (s) i will be a list created by user i during step s of the protocol, while v (s) i,c will denote the c-th component of said list.As shorthand, 1 denotes a list where each component is equal to 1, and similarly 0 denotes an all-zero list.
As in [7] and [10], the notation # (s) i (v, c), for 1 ≤ c ≤ m represents the number of players from which player i has received during step s a valid message containing a list v (s) = (v 1 , . . ., v m ) such that v c = v considering, possibly, also its own message.We recall that honest players consider at most one message from player j as valid (discarding all contrasting and not properly formatted messages, and counting identical messages as one), so only valid messages are considered and counted, and v # (s) In the protocol the players try to reach agreement on a list of arbitrary values, where each player j starts the protocol knowing an m-dimensional list We say that the players have reached cagreement, where 1 ≤ c ≤ m is a specific component, when there exists v ∈ V c such that for every honest player j, v j,c = v.When c-agreement is reached on all the components of the list, we have that for all honest players i, j, v i = v j , hence also agreement is reached.

Cob Protocol
We now present Cob, a protocol that allows a wide gossiping network to reach agreement on a list of arbitrary values.The properties of the protocol will be formally stated and proved in Section 4.

Protocol Parameters and Components
For the sake of clarity and easy reference, we now provide a list with the definition of the parameters and the notation that we will use to describe and analyze Cob: -H: a cryptographic hash function, modelled as a random oracle; -(G, S, V ): a digital signature scheme with unique signature (see Definition 2.1); -N ∈ Z + : the number of nodes in the network, i.e. the users of the protocol; -PK: the set of public keys of the users, each user i, with 1 ≤ i ≤ N , is univocally identified by its public key pk i ∈ PK and has a private key sk i ; -2 3 < h ≤ 1: the ratio of the honest users in PK; r: a reference string, i.e. a random string independent from every pk i ∈ PK and known by every user; n: the expected number of players active in each step of the protocol; t H = 2n 3 + 1: a threshold used in the protocol, derived from the expected lower bound of the number of honest players in each step; m: the number of components of the list of arbitrary values upon which agreement has to be achieved, and which is common knowledge since the nodes know the events they must observe and describe on the ledger; -V = m c=1 V c : the set the list to be agreed upon belongs to, each set V c contains all the possible values of the c-th component of said list; -⊥: a special value that represents a non meaningful value for any component, we require that ⊥ ∈ V c for every 1 ≤ c ≤ m; -O i ∈ V : the list built by player i at the start of the protocol, for every 1 ≤ c ≤ m we will say that c is an for every couple of honest users i, j, otherwise, if there exist two honest users i and j such that O i,c = O j,c , we will say that c is an ambiguous component; -Ω: the amount of time spent by each player i at the start of the protocol to build its private list O i (e.g. by observing some events and reporting some relevant information about them), the protocol will then try to reconcile all these lists into a shared one; -Λ: the upper bound to the time needed to propagate the messages in each of the first two steps of the protocol; λ: the upper bound to the time needed to propagate the messages of the third and following steps of the protocol.The difference between λ and Λ depends on the size of the elements of V .We assume that Λ = O (λ); s ∈ Z + : the current step of the protocol; -P (s) : the active players that partake in step s of the protocol; σ (s) i = S (sk i , H (r s)): the credential of user i for step s, used to check if i ∈ P (s) ; p ∈ (0, 1): for each time-slot s, each user in PK is chosen to be in P (s) with probability p = n N ; -MP (s) and HP (s) : they are respectively the set of malicious and honest players in step s, note that MP (s) ∪ HP (s) = P (s) and MP (s) ∩ HP (s) = ∅; m (s) i : the message broadcast by player i during step s; -v (s) i : the list of information contained in the message m (s) i , we will see that v , S (sk i , s x)): the value x broadcast by player i during step s certified by its signature, it is included in m (s) i ; -C i : the certificate built by player i which attests that the final list has network agreement, each user i continues running the protocol until it can build a certificate C i ; α i ∈ [0, λ]: the time at which user i starts the execution of each step of the protocol; β (s) i : the time at which user i ends the execution of step s of the protocol; t (s) : the amount of time that players of step s have to wait in order to harvest all the information required to compute the message to broadcast, if i ∈ P (s) then t (s) = β (s) i − α i ; -T c : the time at which the first honest user finalizes component c; -T : the time at which the first honest user produces a certificate; -L: a random variable representing the number of Bernoulli trials needed to see the output 1, when each trial outputs 1 with probability h 2 ; χ l, h 2 : a random variable representing the number of steps required to end the probability game described in [10] with parameters l and h 2 .The probability game consists into flipping l distinct but equal coins (which flip heads with probability h 2 ) until each of them flipped head at least once.Its probability distribution is computed in [10] but is also reported in Section 5.1.

Cob Protocol Description
We now describe in detail how Cob works.The honest users will be the ones who follow the protocol described below, and, even if not elected as players on any step, they are supposed to stay online to support message propagation during the whole protocol execution.
The protocol is a variant of the MBA, where the first three steps are essentially the Multidimensional Graded Consensus presented in [10], then from the step 4 onward it is a three-step loop that corresponds to the Multidimensional Binary Byzantine Algorithm, also presented in [10].
As in the protocol MBA, each user i privately saves a list f i initialized to 0 that keeps track of the finalization of the components.A component is finalized when the network is in agreement on it, and from that moment on the protocol will not change it anymore.Once every component has been finalized, the protocol enables the creation of certificates that attest that the list is indeed shared by the network, and then terminates.That is, the threestep loop is repeated until the ending condition is met, which corresponds to the creation of a certificate for the agreed-upon final list.
Every honest user i in the system starts the protocol execution when its own private clock signs 0. Note that, right from the start, each user i can build its credentials σ (s) i and check for which s it will be φ H σ (s) i ≤ p and therefore i ∈ P (s) .
We now describe Cob, followed by the Ending Condition to be performed in each step s ≥ 4 to determine whether agreement has been achieved.

STEP 1 (first step of m-dimensional GC)
-Each user i computes its credential σ (1) i and checks if i ∈ P (1) ; if i ∈ P (1) then i ends its step 1 right away; if i ∈ P (1) , i spends t (1) = Ω time building its own private list O i ∈ V , then: i , if i ∈ P (2) then i ends its step 2; if i ∈ P (2) , after waiting an amount of time t (2) = t (1) + Λ + λ, player i does the following: i , where v

and v
(2) i,c = ⊥ otherwise; broadcasts the message: STEP 3 (output determination of m-dimensional GC and starting broadcast in m-dimensional BBA) -Each user i collects and locally saves the messages received from the players of step 2; after waiting an amount of time t (3) = t (2) + λ + Λ, i updates its private list O i and computes the list g i where, for each component c, O i,c and g i,c are computed as follows: if, for some x = ⊥, # 3) , then i ends the execution of step 3; if i ∈ P (3) , then player i does the following: builds the list v i,c = 1 otherwise; computes the list Θ -Each user i collects the messages received from the players active during step s − 1; after waiting an amount of time t (s) = t (s−1) +2λ, the user i starts building the list v (s) i performing the following operations: for all 1 ≤ c ≤ m such that f i,c = 1; performs the FINALIZATION CHECK 0; performs the FINALIZATION CHECK 1; if i ∈ P (s) , the user i ends the execution of step s; if i ∈ P (s) , the player i does the following: completes the list v (s) i depending on the lists v (s−1) j included in the valid messages it has received, in particular, for each component c such that -Each user i collects the messages received from the players active during step s − 1; after waiting an amount of time t (s) = t (s−1) +2λ, the user i starts building the list v (s) i performing the following operations: for all 1 ≤ c ≤ m such that f i,c = 1; performs the FINALIZATION CHECK 0; performs the FINALIZATION CHECK 1; if i ∈ P (s) , the user i ends the execution of step s; if i ∈ P (s) , the player i does the following: completes the list v (s) i depending on the lists v (s−1) j included in the valid messages it has received, in particular, for each component c such that STEP s 6 ≤ s, s − 1 ≡ 2 ( mod 3) (Coin-Genuinely-Flipped step and starting broadcast of Coin-Fixed-To-0 step in m-dimensional BBA) -Each user i collects the messages received from the players active during step s − 1; after waiting an amount of time t (s) = t (s−1) +2λ, the user i starts building the list v (s) i performing the following operations: verifies the ENDING CONDITION; for all 1 ≤ c ≤ m such that f i,c = 1; performs the FINALIZATION CHECK 0; performs the FINALIZATION CHECK 1; if i ∈ P (s) , the user i ends the execution of step s; if i ∈ P (s) , the player i does the following: completes the list v (s) i depending on the lists v (s−1) j included in the valid messages it has received, in particular, for each component c such that • otherwise, letting P (s−1) i ⊆ P (s−1) be the set of players who sent i a valid message in the previous step, then i sets v

ENDING CONDITION
If, while user i waits for the end of the current step (step s), there exist a string θ ∈ {0, 1} d and a step s such that: ; then i can build its certificate C i , diffuse it in the network and terminate its execution of the protocol.
For the collision resistance of H we can assume that there is a list Θ ∈ V such that θ = H (Θ), i.e. i has collected 2t H signatures that refer to the same list Θ. Lemma 4.2 states that in this case i has received, for each 1 ≤ c ≤ m, at least a message m (2) j,c = Θ c , hence it can reconstruct the list Θ.Let P(s−1) ⊆ P (s−1) and P(s) ⊆ P (s) be the the sets of players (each of cardinality at least t H ) that have sent messages with the signature of H (Θ) as stated above, then i can build its certificate as: .

FINALIZATION CHECK 0
Let s be a step such that 4 ≤ s ≤ s and s − 1 ≡ 0 mod 3 (that is, step s is a Coin-Fixed-To-0 step).
For each component c ∈ {1, . . ., m} such that f i,c = 0, if, considering the lists v (s −1) j contained in the valid messages m (s −1) j received by i, we have that

FINALIZATION CHECK 1
Let s be a step such that 4 ≤ s ≤ s and s − 1 ≡ 1 mod 3 (that is, step s is a Coin-Fixed-To-1 step).
For each component c ∈ {1, . . ., m} such that f i,c = 0, if, considering the lists v (s −1) j contained in the valid messages m (s −1) j received by i, we have that User i keeps following the protocol instruction until the ending conditions are satisfied and i is able to build a certificate C i .A certificate C i contains the list Θ on which the network has reached agreement, alongside a set of digital signatures for H (Θ) together with a proof that those who signed were indeed players of a specific step.In particular C i contains at least t H signatures from players of a Coin-Genuinely-Flipped step s and t H signatures from players of the subsequent subsequent Coin-Fixed-To-0 step s + 1.

Security Analysis
We now outline the security proof for the protocol Cob.In the main theorem, Theorem 4.1, we determine: 1. an upper bound to the time needed by the first honest node to produce a certificate for the agreed upon list Θ; 2. the time interval when every honest user gets to know Θ.
In order to prove this, in Section 4.1 we show some preliminary results characterising the gossiping communications under our assumptions, and prove a lemma that justifies the construction of a certificate as described in Section 3.2.
In Section 4.2 we prove some propositions and lemmas regarding the time needed by a network of nodes to reach consensus on the single list components.In particular we distinguish two cases: 1. if the nodes observed unambiguous events (i.e. the honest nodes agree on the same value at the beginning of the protocol) or very ambiguous events (which means that there is not a majority of the nodes who observed the same value), then they will reach c-agreement within step 5; 2. otherwise, the number of steps required to reach c-agreement is upper bounded by 3L + 5, where L is a Bernoulli-like random variable with parameter h 2 > 1 3 .Finally, we use the results above to prove that the nodes of the network will be in possess of a certificate for the agreed upon list Θ within a number of steps upper-bounded by 5 + 3χ , h

2
, and that only one list can be certified.Theorem 4.1 (Main Theorem) Given an instance of Cob, described in Section 3.2, the following properties about each protocol execution hold with overwhelming probability: 1. if 0 ≤ ≤ m is the number of ambiguous components, then we have that is the random variable described in [10]; 2. all honest users agree on the same list Θ and know it in the interval [T, T + λ].
Remark 4.1 When there are no ambiguous components, i.e. all honest nodes at the beginning of the protocol build the same list, then we have χ , h 2 = 0, so T ≤ Ω + 2Λ + 7λ.

Preliminary Results
In order to prove our Main Theorem 4.1, we first need to prove some preliminary lemmas and propositions which characterize Cob under our communication and network model.Lemma 4.1 For each step s ≥ 1 of a protocol run we have: it has received all messages sent by all honest players j ∈ HP (s ) for all steps s < s; 3. for each step s > s, fixing a component 1 ≤ c ≤ m, with overwhelming probability there do not exist two players i, i ∈ P (s) such that: i has received at least than t H messages m Proof Property 1 holds as a consequence of the network assumptions regarding the same speed clocks delay.In fact we know that each user i starts its protocol execution at a time α i ∈ [0, λ] and waits for time t (s) before acting and then ending its step.This means that β Property 2 holds by the definition of the protocol, noticing that t (s) ≥ t (s ) for all s < s.If s = 2, 3, then for all s < s, i ∈ P (s) , we have that since the honest players j ∈ HP (s ) send their messages of step s at time β (s ) j and the messages reach all honest users in at most Λ time, then player i has received all the messages from honest players of the previous steps.If s ≥ 4, then: since each honest player j ∈ HP (s ) sends its message of step s at time β (s ) j , then it will reach all honest players by time β (s ) Finally we prove Property 3. Let us assume for sake of contradiction that the two players i, i and the two values b, b of Property 3 do exist.Note that each malicious player j ∈ MP (s) may have signed both a list v Therefore, at least t H − MP (s) of the messages received by i advertising b must come from a set H of honest players, and t H − MP (s) must come from another set H of honest players with H and H disjoint sets.Note that the messages advertising different values in the c-th component must be distinct messages, this means that we are considering at least 2t H distinct messages.
Let M be this set of at least t H messages collected by i and M the analogous set of messages collected by i , then: where the last inequality holds with overwhelming probability thanks to the assumptions of Definition 2.4.This is a contradiction, therefore such players i and i do not exist.Now we prove a lemma that justifies the construction of a certificate as described in Section 3.2.In particular, the messages which constitute a valid certificate do not contain the list that the network is certifying, but just its digest.Therefore a node must be able to determine which is the list associated to that digest.In Lemma 4.2 we prove that a node can find the candidate values for each components from the messages it has received in step 2. Lemma 4.2 If a user i builds a certificate C i for the list Θ, then, for each 1 ≤ c ≤ m, i has received at least one step 2 message from j ∈ HP (2) with v (2) j,c = Θ c .Proof Note that from the assumptions of Definition 2.4 on the number of malicious players we have that 2 , so at least one of the signatures in the certificate C i must come from an honest player k ∈ HP (s) .Then k must have received, during step 3, at least tH 2 messages for Θ c in c-th component.Again, since |MP (s) | < tH 2 , at least one of them must come from an honest player j ∈ HP (2) and, according to Item 2 of Lemma 4.1, his message must have reached also i within time β (3) i .
To conclude, note that β (3) i is the ending time of step 3 for player i and it is before any possible certificate production time.

Component-Wise Finalization
In this section we prove some properties about the finalization of a single component, distinguishing between the associated ambiguous and unambiguous events to be recorded.
We recall that the finalization checks are performed after every step s ≥ 4 and refer to messages exchanged during step s ≥ 3, and s ≡ 0 mod 3 (i.e.STEP 3 and all subsequent Coin-Genuinely-Flipped steps) for what concerns FINALIZATION CHECK 0 and step s ≥ 4, and s ≡ 1 mod 3 (i.e.all Coin-Fixed-To-0 steps)for what concerns FINALIZATION CHECK 1.

Unambiguous Components
In the following proposition we will show how the network behaves if the event associated to a specific component is unambiguous.In particular, we will explain, following the protocol steps, why every honest player will finalize that component within the end of STEP 5. all honest users have their c-th component finalized by step 5 (and in particular there is c-agreement on the lists Θ (s) i for all s ≥ 5); -T c ≤ t (5) + λ.
Proof Note that every honest player i ∈ HP (s) starts its step s at time α i ∈ [0, λ].Now we analyse the protocol step by step.STEP 1 Since component c is unambiguous, then for a certain value x ∈ V c each honest player i ∈ HP (1) will build a list v i,c = x.Then i will propagate its message m (1) i at time β (1) i = α i + Ω. STEP 2 When an honest player i ∈ HP (2) stops waiting at time β (2) i = α i + t (2) , i has received all step 1 messages sent by the other honest players.By our assumptions we have, with overwhelming probability, |HP (1) i,c = x and broadcasts the message m (2) i containing the digital signature of this list.STEP 3 When an honest player i ∈ HP (3) stops waiting at time β (3) i = α i + t (3) , i has received all step 2 messages from all the honest players.Since the lists in their messages m (2) j,c = x, and with overwhelming probability |HP (2) | > t H , then player i will set (O i,c , g i,c ) = (x, 2) if x = ⊥, (O i,c , g i,c ) = (x, 0) if x = ⊥.So, i will build the list v and broadcast its message m (3) i .STEP 4 When an honest player i ∈ HP (4) stops waiting at time β (4) i = α i + t (4) , i has received all step 3 messages from all the honest players.We now consider separately two cases: x = ⊥, in this case player i enters the FINALIZATION CHECK 0 (4−1 ≡ 0 mod 3) and since the number of honest players is |HP (3) | ≥ t H with overwhelming probability, player i sets v i,c = 0 and f i,c = 1.This means that all honest players have finalized the c-th component of the list and they will get Θ (s) i,c = x for all s ≥ 4.
x = ⊥, in this case player i will neither enter the ENDING CONDI-TION nor any FINALIZATION CHECK.It will build a list v i,c = 1 since with overwhelming probability |HP (3) | > t H . Player i will broadcast its message m (4) i containing the digital signature of v (4) i .Thus c-agreement has been reached if x = ⊥, otherwise we will see that it will be reached in the next step.STEP 5 When an honest player i ∈ HP (5) stops waiting at time β (5) i = α i + t (5) , i has received all step 4 messages from all the honest players.Again, we consider two cases: x = ⊥, in this case c-agreement on lists Θ (s) i has already been reached, and the c-th component has already been finalized by the honest players.
x = ⊥, in this case, i has received with overwhelming probability at least t H messages from all the other honest players j ∈ HP (4) containing the digital signature of a list v Since the malicious players are less than t H , they will not be able to produce the number of messages required to mislead the honest players.We have seen that by the end of step 5 all honest users have finalized the c-th component (and they are in agreement with each other), so we have that T c ≤ t (5) + λ.

Ambiguous Components
Let us now tackle the more difficult case of ambiguous components.In Proposition 4.2 we deal with the simpler sub-case, when no honest player sets g i,c = 2 during step 3, which means that there is a wide disagreement among the network about that specific component.As we will see, this case will resolve with the achievement of agreement on the symbol ⊥.
Then, we complete the analysis by considering the case when some honest node sets g i,c = 2.In Lemma 4.3 we prove that in this case each honest user j has saved the same value O j,c = x ∈ V c at the beginning of step 3.They do not know yet that they already are in agreement, so each of them tries to figure out whether to preserve that component of the final list or to discard it by setting it to ⊥.This decision will be made by exchanging the bit lists from step 3 onward.In fact, as it is stated in Lemma 4.4, once c-agreement is reached on the bit list either on 0 or 1, it is also reached on the list Θ j ∈ V respectively on x ∈ V c or ⊥.
Then, it becomes essential to prove that c-agreement is achievable on each component with probability 1, and also to upper-bound the time required to achieve it.To do that, we prove in Lemma 4.5 that the network will reach c-agreement on the bit list with probability greater than 1  3 after every Coin-Genuinely-Flipped.Therefore, in Lemma 4.6 we prove that c-agreement is eventually reached with probability 1 and that all the honest nodes will fi-nalize the component c with the same value finalized by the first node in the network who can do it (even if the first user who can finalize the component is malicious).
These Lemmas are then used to prove Proposition 4.3, where we present an upper bound to the number of steps and time required to finalize a single component.Finally, the results of the previous lemmas and propositions are used to prove Theorem 4.1.
Proposition 4.2 (c-Agreement on Very Ambiguous Components) Let c be an ambiguous component and assume that all honest step 3 players set g i,c < 2, then with overwhelming probability we have that: all honest users have their c-th component finalized (in particular will be in c-agreement on the list Θ Proof By definition of the protocol Cob, for each i ∈ HP (3) , i sets v  This means that the honest users reach c-agreement on Θ (s) i,c = ⊥ by the end of step 5 (which happens in the interval [t (5) , t (5) + λ]), and it will hold for all s ≥ 5. Note that in this case, a strong disagreement among the players results in the component to be set to ⊥ as it happens in Proposition 4.1 when every honest players starts with ⊥.Proposition 4.3 (c-Agreement on Ambiguous Components) Let c be an ambiguous component and assume that there exists a player i ∈ HP (3) which sets g i,c = 2, then: all honest users have their c-th component finalized (in particular will be in c-agreement on the list Where L is a random variable representing the number of Bernoulli trials needed to see the output 1, when each trial outputs 1 with probability h 2 .
In order to prove Proposition 4.3 we need the results stated in the following four lemmas.Lemma 4.3 Under the assumption of Proposition 4.3, we show that the following properties hold: 1. g j,c ≥ 1 for all j ∈ HP (3) ; 2. there is a value x ∈ V c such that O j,c = x for all j ∈ HP (3) .
Proof Since player i ∈ HP (3) is honest and sets g (3) i,c = 2, then: k,c = x.By Property 3 of Lemma 4.1 we know that no honest player j ∈ HP (3) As showed in the proof of Lemma 4.2, we have that with owerwhelming probability |MP (s) | < tH 2 , so we can state that more than tH 2 honest players must have signed for x.Therefore, if g j,c = 1, and Property 1 holds.2. We now show that, even if j sets g j,c = 1, it will set O j,c = x.In fact, there can not exist a value x = ⊥ and x = x such that j has received also more than tH 2 step 2 messages m k,c = x .For the sake of contradiction, we suppose that these messages exist; many of them may come from malicious players in MP (2) , but at least one of them must come from an honest player p ∈ HP (2) .This means that p has received t H step 1 messages m (1) k,c = x .Since we have seen that some other honest step 2 players have signed a step 2 message advertising v Proof Since the honest player i ∈ HP (3) sets g i,c = 2, it will set v i,c = 0, therefore it is possible that c-agreement is reached on 0. By the analysis of Property 2 of Lemma 4.3 the honest users may not have an agreement on their v (3) i,c at the end of step 3 but they will have an agreement on O (3) i,c = x.This means that, by the definition of Cob, when c-agreement is reached on the bit list (either on 0 or 1), then it will also be reached on x in Θ (respectively on x or ⊥).Remark 4.2 This property is true also in the general case, but we have explicitly proved it only under the assumptions of Proposition 4.3.
Lemma 4.5 Being c a component on which agreement among the honest user does not hold, at every Coin-Genuinely-Flipped step c-agreement is reached with probability at least h 2 .
Proof Assuming that c-agreement is not reached at the beginning of a Coin-Genuinely-Flipped step s where s ≥ 6, s − 1 ≡ 2 mod 3, let an honest player i ∈ HP (s) be in the condition that it must flip the coin during such step.This means that the player i has not received more than t H messages for a bit b ∈ {0, 1} in component c, so i selects its own coin flipper , and i will set v , where H (K) c is the c-th bit of H (K).
Note that, by Lemma 4.1, if an honest player has seen more than t H messages for the same bit b in component c, then no honest player has seen more than t H messages for 1 − b in the same component.This means that i will be in c-agreement with the honest players who did not flip the coin only if b i = b, and this happens with probability 1  2 with the Random Oracle assumption for the hash function H.
Therefore, all honest players in HP (s) will be in agreement with probability 1 2 .Actually, this is true if the coin flipper is an honest player, in fact in this case b i can be assumed to be randomly chosen and globally shared among the honest players flipping the coin.If the player with minimal hashed credential is a malicious player, then we cannot say much about the probability distribution of the output of the bit extraction, since some players may not have seen its message.
However, with our assumptions on the common reference string r, we can state that, with probability h, the coin flipper will be honest, and in this case all honest players will be in agreement with probability 1  2 .Combining these two independent probabilities we get that with probability at least h 2 the honest players reach c-agreement every time they enter a Coin-Genuinely-Flipped step.Note that they will finalize this component within the following 2 steps: in s + 1 if b i = 0, in s + 2 if b i = 1.Lemma 4.6 Under the assumptions of Proposition 4.3, we have that: 1. being E the event "there exists a step ŝ ≥ 4 such that, for the first time, some user î ∈ PK (either malicious or honest) should finalize its c-th component of list v î ", E happens with probability 1; 2. T c ≤ t (ŝ+3) + λ and c-agreement is reached in step ŝ on the same value finalized by î (however, the c-th component might be finalized 3 steps later).
Proof 1.As proven in Lemma 4.5, if c-agreement is not reached by the honest users, at every Coin-Genuinely-Flipped step they will reach it with probability at least h 2 > 1 3 .Therefore, once every 3 steps the c-th component will be finalized with probability greater than 1  3 , therefore the probability that the event E happens converges to 1.

2.
Step ŝ is the first step in which a user î can finalize the c-th component.
By the construction of the protocol, this happens in two possible ways: E a : î is able to collect or generate (and then propagate) at least t H valid messages m k,c = 0, 4 ≤ s ≤ ŝ, and s − 1 ≡ 0 mod 3; E b : î is able to collect or generate (and then propagate) at least t H valid messages m = 1, 4 ≤ s ≤ ŝ, and s − 1 ≡ 1 mod 3; Because the messages produced during step s − 1 by honest players are received by every user before they are done waiting in step s , and because the adversary receives everything no later than the honest users, without loss of generality we can assume that s = ŝ, and that the user î is malicious.For any step s ≥ 4, every honest player i ∈ HP (s) who has waited time t (s)  has received all honest step s − 1 messages (thanks to Lemma 4.1), and all honest players in HP (s) have set O i,c = x (according to Lemma 4.3).We now consider step ŝ and examine 4 exhaustive ways in which event E may happen.Case 2.1.a:event E a happens and there is an honest user i ∈ PK who should also finalize the c-th component.
In this case, we have ŝ−1 ≡ 0 mod 3, hence Step ŝ is a Coin-Fixed-To-0 step.By assumption, i has received at least t H valid step ŝ−1 messages m i ,c = 0 and f i ,c = 1.Now we show that any other honest user i has either finalized its c-th component, setting v i,c = 0.For step ŝ + 1, since user i has helped propagating the messages that have let it finalize the c-th component on or before time α i + t (ŝ) , then on or before time β (ŝ+1) i each honest user i has received at least t H valid ŝ − 1 messages for the bit 0. In fact, even if some of the t H messages received by i were not broadcast in time by a malicious user, within time β (ŝ+1) i they have reached i, for all i ∈ PK.This is true because user i received the messages within time β (ŝ) i and helped propagating them, hence within time β (ŝ) i + λ they have reached all honest players, and for all honest players i ∈ HP (ŝ+1) we have: Furthermore, honest players will not end step ŝ + 1 before receiving those step ŝ − 1 messages, because there do not exist other t H valid step s − 1 messages for 1 in the component c with s − 1 ≡ 1 mod 3 and 5 ≤ s < ŝ + 1, by the definition of Step ŝ in assumption E a (step ŝ is the first step in which a user should finalize component c).
In particular, step ŝ + 1 itself is a Coin-Fixed-To-1 step, but no honest player has propagated during step ŝ a message for 1 (as we have shown they have reached c-agreement on 0), and |MP (ŝ) | < t H . Thus all honest users finalize their c-th component, setting v So, we have proven that, for all s ≥ ŝ + 1, the honest users set v (s) i,c = 0 and f i,c = 1 (i.e. they finalize the component c within the end of step ŝ + 1).We have already seen that ∃x ∈ V c such that O i,c = x for every honest user i, so they will set Θ message.Since i has helped propagating the step ŝ − 1 messages it has received by time α i + t (ŝ) , all honest users finalize the c-th component during step ŝ + 1.Again, they will reach c-agreement over ⊥ on Θ (s) i for all s ≥ ŝ, they will set v (ŝ+1) i,c = 1 and f i,c = 1, finalizing the component c within the end of step ŝ + 1. Case 2.2.a: event E a happens and there does not exist an honest user i ∈ PK who should also finalize c-th component.
In this case, note that î could have received or generated t H step ŝ − 1 messages with v = 0.However, the malicious users may not help propagating those messages, so we cannot conclude that the honest users will receive them after time λ.In fact, |MP (ŝ−1) | of those messages may be from malicious players, who did not propagate their messages at all and only sent them to the other malicious players cooperating with them.
Therefore, the honest users will wait for time t (ŝ) without finalizing component c.However, by Property 4 of Lemma 4.1, they will not see more than t H of the messages received with v = 1, again because with overwhelming probability |HP (ŝ−1) | + 2|MP (ŝ−1) | < 2t H . Since step ŝ is a Coin-Fixed-To-0 step, every honest player i ∈ HP (ŝ) thus sets v (ŝ) i,c = 0 and propagates its message at time α i + t (ŝ) .During step ŝ + 1, which is a Coin-Fixed-To-1 step, two things may happen: 1 an honest user receives the t H messages received by î (who decided to propagate them and let it finalize component c): in this case the situation is similar to Case 2.1.a,and every honest user i will finalize its c-th component within time α i + t (ŝ+1) + λ; 2 the honest users will receive at least |HP (ŝ) | (> t H with overwhelming probability) messages with v k,c = 0 from the honest players.Then they propagate their messages with v (ŝ+1) i,c = 0 but do not finalize since step ŝ + 1 is not a Coin-Fixed-To-0 step.In this case, in step ŝ + 2 which is a Coin-Genuinely-Flipped step, two things may happen: 2.1.if î broadcasts the step ŝ − 1 messages that let it finalize its c-th component, then the honest users will finalize their c-th component as well setting v i,c = x for all s ≥ ŝ + 2 within time α i + t (ŝ+2) ; 2.2.otherwise all honest users have received all step ŝ + 1 messages from the honest players with v = 0. Again they are more than t H , so the honest users set v = 0 without flipping the coin.Again, they do not finalize component c since ŝ + 2 is not a Coin-Fixed-To-0 step so they just broadcast their step ŝ + 2 messages.Finally, step ŝ + 3 is a Coin-Fixed-To-0 step, so everyone will receive at least t H messages with v (ŝ+2) i = 0 where i ∈ HP (ŝ+2) .Then all honest users k at time α k + t (ŝ+3) can finalize component c setting v The analysis in this case is similar to Case 2.1.band Case 2.2.a, thus many details have been omitted.We know that î has collected or generated at least t H step ŝ−1 messages with v = 1 and ŝ − 1 ≡ 1 mod 3 (hence ŝ is a Coin-Fixed-To-1 step) and that no honest player could have seen more than t H messages for 0. Thus each honest player i ∈ HP (ŝ) sets v Proof (Proof of Proposition 4.3) Given the results of Lemma 4.6, it remains to upper-bound ŝ and thus T c .We do that by considering how many times the Coin-Genuinely-Flipped steps are executed by at least one honest player.
If no honest player flips the coin in a Coin-Genuinely-Flipped step s, it means that they all have received more than t H messages with v By Lemma 4.5, at every Coin-Genuinely-Flipped step c-agreement is reached with probability at least h 2 , so we can compare this step to a Bernoulli trial that outputs 1 if c-agreement is reached.This means that, before step ŝ (the first step in which a user can finalize the c-th component), the distribution of the number of times the Coin-Genuinely-Flipped steps are executed to finalize a component c can be upper-bounded by to the random variable L, which we recall represents the number of Bernoulli trials needed to see a 1 when each trial gives 1 with probability h 2 > 1 3 .Letting s be the last Coin-Genuinely-Flipped step before the finalization of the c-th component, then we have, by the protocol construction, s = 3 + 3L.
Assuming that the adversary knows the outcome of L in advance, when should the adversary make step ŝ happen to maximize the delay of the finalization time T c of the c-th component by an honest user?If ŝ > s (hence ŝ = s + 1 or ŝ = s + 2) then this means that we are in Case 2.1.aor Case 2.1.b of Lemma 4.6 since at the end of step s the honest players are already in agreement, so when a malicious player could finalize, also the honest users can, hence If ŝ < s − 3, that is ŝ is before the second to last Coin-Genuinely-Flipped step, then by the analysis of Case 2.2.a or Case 2.2.b we get that is, the Adversary is making the agreement on component c happen faster.
If ŝ = s − 1 or ŝ = s − 2, then ŝ is the Coin-Fixed-To-0 or Coin-Fixed-To-1 step before s .By the analysis of the 4 sub-cases we know that the honest players never flip the coin and finalize the c component within the next two steps.Therefore, the following holds: To summarize, no matter what ŝ is, we have: which upper-bounds the time needed to reach agreement on the c-th list component.Now we will prove Theorem 4.1, using the results of the previous lemmas and propositions.We will prove that all the honest users will agree on the same Θ, that no malicious user can build a valid certificate for a different Θ, and that the honest users will be able to produce a certificate for Θ within time t 5+3χ , h 2 + λ.We also prove that only one list can be certified, therefore the nodes will reach agreement on a list and it is not possible for the malicious users to produce a valid certificate for another list.This guarantees the consistency property of Cob.
Proof (Proof of Theorem 4.1) It is sufficient to note that, since t (s+1) = t (s) + 2λ for all s ≥ 3, we have that: = t (1) + t (2) − t (1) + t (3) − t (2) Let m − be the number of unambiguous components, we have shown in Proposition 4.1 that these components will reach agreement in at most 5 steps.The same will happen for some of the ambiguous components according to Proposition 4.2, while the others, as shown in Proposition 4.3, will reach agreement within a number of steps whose distribution is upper-bounded by the random variable 3L + 5.
Cob runs until a certificate for a list Θ ∈ V is created, this happens no later than the moment in which every component is finalized by the honest players, which happens once c-agreement is reached on each of the ambiguous components.
Since we have shown in Lemma 4.5 that with probability at least h 2 the honest players will reach c-agreement on a single component, and once agreement is reached it is maintained for the whole protocol run, then agreement will be reached in at most χ , h 2 Coin-Genuinely-Flipped steps (accordingly to the analysis in Proposition 4.3, malicious users might speed the consensus process up!) where χ , h 2 is the same random variable described in [10].
Every honest user will be able to obtain a certificate for a block at the end of the two steps following the χ , h 2 -th Coin-Genuinely-Flipped step according to the definition and analysis of Cob shown above.Therefore it holds that Now we show that if a certificate is created for the first time in step s for a list Θ ∈ V , then any certificate created will be for the same list Θ.
Let step s be the first step in which a user k is able to collect a certificate C k for Θ.We recall that, by the assumptions in Definition 2.4, given two distinct players i, j ∈ P (s) of the same step, it is negligible the probability that i collects t H messages for a list Θ (s−1) i and j collects t H messages for a distinct list Θ (s−1) j .As before, we can assume that the user k is malicious and the certificate is made of step s − 2 and step s − 1 messages, where step s is a Coin-Fixed-To-1 step.
We distinguish two cases: -There is an honest user k who also can collect a certificate C k for Θ in step s.
In this case k has propagated the messages which let it certify the list Θ, hence all honest users will be in possess of a certificate (possibly a different one) for the same list Θ, so the honest users will agree on the same list Θ.Also, the honest users will end the protocol execution, so there is no chance that another certificate is produced in the following steps since with overwhelming probability MP (s) < t H ∀s. -There is no honest user k who also can collect a certificate C k for Θ in step s.
In this case the honest users will keep executing the protocol until they can create a certificate for a block Θ or until they receive from k the messages that allowed k to create the certificate in step s.
We will show that if they do not receive the certificate from k, then they will build a certificate for Θ = Θ.This guarantees that honest users will agree on the same list, since there are no two valid certificates around the network for two distinct lists.Therefore, all the honest players send, in step s, a message with 1 in each component c ∈ I 1 .This brings all the honest users in c-agreement on such components and it will keep holding in the following steps.Now we note that I 0 ∪ I 1 = {1, . . ., m}, hence all the honest users are in agreement on all list components.Therefore, in step s + 3, which is again a Coin-Fixed-To-1 step, they will be able to build a certificate for the list of relevant information Θ using their messages of step s + 1 and step s + 2.

Performance Analysis
Given Problem 1.1 and the context of application of Cob, described in Section 1.2 (i.e. a consensus protocol for incomplete networks with millions of nodes), we present a comparison which highlights the advantages of using the leaderless and parallel protocol Cob instead of executing instances of Algorand to achieve the same result.
For the evaluation we will consider the most relevant use case of Cob, namely the example in Section 1 of a blockchain implementing sharding where the network must agree on the blocks created by each shard.
In our performance analysis we will compare the total amount of data that is broadcast by the nodes to let the network reach consensus with the two approaches.We quantify the amount of data broadcast by the network to reach consensus on a list of ambiguous events (which are the most problematic case, hence the worst case scenario) when the ratio of honest users is 80% (i.e.h = 0.8) and the expected number of players in each step is n = 4000, this choice of parameters which reflects the one used in [7].
First, we will determine the expected number of steps in which the elected players broadcast their messages before producing a certificate both for Cob and for Algorand.Then, we will approximate the weight of the messages broadcast in both protocols, and finally we will compare the total amount of data broadcast as the parameter , the number of ambiguous components, changes.

Expected Number of Steps
Starting with Cob, let us make explicit the probability distribution of the random variable χ , h 2 used to upper-bound the number of steps needed to reach consensus.In the analysis of protocol MBA [10], the probability distribution of χ , h 2 is shown to be: from which it is possible to compute the expected number of loops of Coin-Fixed-To-0, Coin-Fixed-To-1 and Coin-Genuinely-Flipped steps the network must execute if the adversary manages to delay as much as possible the consensus achievement.Theorem 4.1 states that the number of steps needed to produce a certificate for the agreed upon list is 5 + 3χ , h

2
, therefore the last step in which messages are broadcast is step 4 + 3χ , h

2
. This means that the expected number of protocol steps with message broadcasting that are needed to produce a certificate can be computed as: With Algorand, the expected number of loops required to bring the nodes to agreement is 2 h .Before entering the loop that performs the binary consensus (Binary Byzantine Agreement [17]), the nodes execute 4 extra steps (Graded Consensus [9]).Finally, in the worst case, the nodes will be able to produce a certificate 2 steps after the last Coin-Genuinely-Flipped step.This means that we must consider one more step with message broadcasting after the last Coin-Genuinely-Flipped step.Therefore, the expected number of steps with message broadcasting required by Algorand is: This is the expected number of steps to reach consensus on a single event.Note that the network must execute an instance of Algorand for each of the events they observe.

Weight of the Messages
We begin with Algorand: in the first step Algorand selects a small number of nodes (e.g.35 potential leaders) who must broadcast their proposal, namely the hash of a block created by a shard plus a verifiable credential.The following steps are expected to be performed by 4000 nodes who broadcast messages of 200 bytes as specified in [7].Since in this use case the weight of the step 1 messages is close to the weight of the other steps, but the number of messages broadcast is much less, we can neglect it while determining the whole amount of broadcast data.The messages created from step 4 onwards weigh around 200 bytes (see [7]) and contain the signature of a single bit, the signature of a digest and a verifiable credential.Finally, the messages created in step 2 and step 3, contain the signature of a digest (the digest of the block created by a shard) together with the verifiable credential of the selected player, therefore we approximate the weight of credential and signature to around 100 bytes, and add the weight of the digest, i.e. 32 bytes, for a total of 132 B.
With Cob, in the first two steps the nodes of the network broadcast a message containing the signature of the list of digests of the blocks created by the shards, together with the verifiable credential of the node who created the message.The weight of such messages can be approximated, with the same reasoning as before, to 32 + 100 bytes.In the following steps, the nodes produce messages containing the signature of a list of bits, the signature of a digest and a verifiable credential.These messages weight around 8 +200 bytes, because they contain the same data as a message of a step s, with s ≥ 4, of Algorand, once we substitute the single bit of Algorand with the bit list of Cob.
In Tables 1 and 2 we summarize the weight of the messages for each step of both Algorand and Cob applied to the sharding use case.In Table 1 the weights are associated to the single steps of each protocol, while in Table 2 the weight of messages are associated to the corresponding protocol phase.

Comparison
We recall that the choice of using a different instance of Algorand for each list component comes from the considerations of Section 1.1.1 and Section 1.1.2.Recall that Algorand is a leader-based consensus protocol, so it is preferable to have one leader (and one protocol instance) for each single event, in order to let consensus achievement on each single component to be independent from the others.In fact, if we used Algorand on the whole list (only a single instance of Algorand), then disagreement on a single component would cause the whole list to be discarded.Therefore, we proceed with the comparison between the execution of Cob and the multiple instances of Algorand.Weight of messages of each step in a single run of Cob and Algorand.The symbol ( ) recalls that the first step of Algorand will not be considered in our comparison.The parameter is the number of events the network must observe.The dimensions reported are derived from the analysis of [7].

Algorand
We can put the information of Table 1 together and compute the amount of data broadcast in the network in a single Algorand run.As we mentioned earlier, we will not consider the messages broadcast in the first step because their contribution is practically negligible.
We also recall that, since Algorand is a leader-based consensus protocol, a malicious leader might deliberately produce a proposal which finds all (or the majority) of the nodes in the network at odds.In this case the consensus process drops to the symbol ⊥ and a certificate is built with step 5 messages.This means that even if the event the network observes is ambiguous, if a leader acts maliciously, agreement will be reached fast.Therefore, since it is not possible to predict how a malicious leader will act, in our comparison we will consider the two border cases: the case when the leader acts honestly, and the case in which every malicious leader will broadcast a controversial message making the consensus drop to ⊥ in 5 steps.
Case 1.If all leaders (i.e. the players of step 1) act honestly, the amount of data broadcast in the network in a single run is expected to be: Case 2. If all malicious leaders cause the drop of their event data, the total weight slightly decreases.Recall that, in Algorand, a leader is honest with probability at least p h = h 2 (1 + h − h 2 ) (see [7]).In this case every instance of the protocol whose leader is malicious will end after the broadcast of step 5 and the consensus drops to ⊥.This means that: Again, multiplying by we obtain the total amount of data broadcast in the network:

Cob
With Cob, the amount of data broadcast in a single protocol run (which covers all the components) can be computed as: To give the idea of how Cob can outperform Algorand, we compute the amount of data broadcast by a network where the percentage of honest users is 80% (i.e.h = 0.8), and the expected number of players that must broadcast a message, in each step is n = 4000 (recall that we are not considering the first step of Algorand).Figures 1 and 2 show the expected total amount of data broadcast for different values of the parameter , the number of ambiguous components.
We recall that, for the analysis of Algorand, we considered the two border cases, namely all the malicious leaders drop their components to ⊥ and no malicious leader makes its component to drop to ⊥.Therefore, in general, the number of MB broadcast in the network in any Algorand protocol execution will reasonably be between the two corresponding lines.

Conclusions
We presented Cob, an extension of the MBA protocol [10] which allows the nodes of a wide gossiping network to reach consensus on a list of arbitrary values, working in parallel on each component.
This generalization widens the applications of the original protocol thanks to the sortition mechanism that limits the number of messages to be broadcast and processed at each step when there are many players, and the relaxed network assumptions which model real-case scenarios more closely.Notice that the protocol retains the leaderless approach of the MBA protocol, a democratic feature that is valued in permissionless distributed settings and thwarts attacks from malicious leaders.Moreover, it also preserves the parallel approach that enhances efficiency with respect to multiple executions of protocols designed to work in the same environment, such as Algorand.
As we explained in Section 1, we believe that one of the most relevant use cases of Cob is as consensus layer to allow the reconciliation of transactions in blockchain platforms implementing sharding.In this context, we proposed a comparison between Cob and the execution of multiple instances of the well-known protocol Algorand, supposing that a network of nodes must reach consensus on which blocks have been legitimately created by different shards.As shown in Figures 1 and 2, Cob remarkably reduces the amount of data broadcast in the network with respect to multiple executions of Algorand, and this would reasonably speed up the consensus process.

Future Works
Cob guarantees to reach consensus if the assumptions are met, and its leaderless and parallel approach maximizes the number of list components that are finalized on a meaningful value (i.e.= ⊥).However its execution is probabilistic, and although it halts with probability 1, the number of steps necessary to halt have only an upper bound in the form of a Bernoulli-like distribution.
An interesting research direction could focus on extending the protocol by introducing some termination steps, in order to have a fixed upper bound on its execution, which would benefit many concrete applications.Specifically, such an extension would see the protocol running normally up to a pre-determined number of steps, then, if the execution has not halted yet, the protocol starts a sequence of termination steps that guarantee to reach a consensus in a fixed number of steps.In this phase it is quite tricky to try to preserve as much meaningful agreement as possible: the trivial solution is to collapse the agreement on ⊥ if consensus is not reached in time, but avoiding to do so has to account for a wide array of attacks with which malicious players could try to disrupt agreement.
= k c , where k = H min j∈P (s−1) to the player whose hashed credential is minimal from i's point of view as the coin flipper selected by i during step s; computes the list Θ (s) i such that Θ (s) i,c = ⊥ when v (s) i,c = 1, Θ (s) i,c = O i,c when v (s) i,c = 0; broadcasts the message:

- 4 ≤
s with s − 1 ≡ 0 mod 3; user i has received at least t H messages m (s −1) j containing the signature of s − 1 θ = s − 1 H Θ (s −1) j and at least t H messages m (s ) j containing the signature of s θ = s H Θ (s ) j = b; i has received at least than t H messages m (s) j advertising v (s) j,c = b with b = b.Note that for step 2 and 3 we have b, b ∈ V c , while for the next steps b, b ∈ {0, 1}.
= b , but all honest players have signed exactly one list, hence their c-th component is unequivocal.

Proposition 4 . 1
(c-Agreement on Unambiguous Components) Let c be an unambiguous component, then the following happens with overwhelming probability:

= 1 .
Then i enters the FINALIZATION CHECK 1 and sets v (5) i,c = 1 and f i,c = 1.This means that all honest players have finalized the c-th component of the list and they will get Θ (s) i,c = ⊥ for all s ≥ 5.
= 1.During step 5, which is a Coin-Fixed-To-1 step, each honest user i will receive all messages by other honest players before β(5) i , hence with overwhelming probability i will receive t H messages for v (4) k,c = 1.Thus i will enter the FINALIZATION CHECK 1 and will finalize the c-th component by setting v (5) i,c = 1 and f i,c = 1.

( 2 )Lemma 4 . 4
k,c = x, this implies that they have seen t H step 1 messages with v (1) k,c = x, which, by Lemma 4.1, is a contradiction.This means that Property 2 holds.Under the assumptions of Proposition 4.3 we have that c-agreement on the list Θ is reached when c-agreement is reached on the bit list v () .
= 0 and f i,c = 1, or has set v (ŝ) i,c = 0 without finalizing such component.Because step ŝ is the first time any player i should finalize component c of the list v (s) i , there does not exist a Coin-Fixed-To-1 step s < ŝ (hence s − 1 ≡ 1 mod 3) such that t H players have signed v (s −1) i,c = 1.Accordingly, no online user in PK finalizes the list component c in step s setting v (s ) i,c = 1.Moreover, if an honest user has waited for a time t (ŝ) , then it must have received all step ŝ − 1 messages from honest players, and (considering the messages received by i ) at least t H − |MP (ŝ−1) | ≥ 1 must have v (ŝ−1) k,c = 0.According to Property 4 of Lemma 4.1, an honest player i cannot collect t H messages with v (ŝ−1) k,c = 1, therefore it sets v (ŝ)

= 1 .
= x and therefore c-agreement reached on Θ (s) i for all s ≥ ŝ + 1. Case 2.1.b:event E b happens and there is an honest user i ∈ PK who should also finalize c-th component.In this case we have ŝ − 1 ≡ 1 mod 3, then step ŝ is a Coin-Fixed-To-1 step.The analysis is similar to Case 2.1.aand we will omit many details.As in the previous case, i must have received t H valid step ŝ−1 messages with v Again, by the definition of step ŝ, there does not exist a step s , with 4 ≤ s ≤ ŝ and s − 1 ≡ 0 mod 3, where at least t H players have signed a message with v (s −1) k,c = 0. Thus, i finalizes the c-th component and sets v (ŝ) i ,c = 1 and f i ,c = 1.Moreover, any other honest user i ∈ PK has either finalized its c-th component if it has received t H messages with v (ŝ−1) k,c = 1 or has set v (ŝ) i,c = 1 and broadcast its m (ŝ) i f k,c = 1 and hence reach c-agreement over Θ (s) k = x for all s ≥ ŝ + 3. Depending on how î and in general the malicious users behave, some users may finalize the component c within the end of step s (with s ∈ {ŝ, ŝ + 1, ŝ + 2}) using step ŝ−1 messages, or within the end of step ŝ + 3 with step ŝ + 2 messages.It does not matter since c-agreement is reached anyway over Θ (s) i for all s ≥ ŝ, the component c is finalized setting f i,c = 1 within step ŝ + 3, and v (s) i,c = 0 for every step s such that s ≥ ŝ + 3. Case 2.2.b: event E.b happens and there does not exist an honest user i ∈ PK who should also finalize c-th component.
i at time α i + t(ŝ) .Similar to Case 2.2.a, within 3 steps user i will finalize their c-th component.Then c-agreement is reached over Θ (s) i for all s ≥ ŝ, and the component c is finalized setting f i,c = 1 within step ŝ + 3 and v (s) i,c = 0 for all steps s, s ≥ ŝ + 3. Combining the four sub-cases, we obtain: -T c ≤ t (ŝ) + λ in Case 2.1.aand Case 2.1.b;-T c ≤ t (ŝ+3) + λ in Case 2.2.a and Case 2.2.b; but we also have that they all are in agreement at the end of step ŝ, and that c-agreement is reached over Θ (s) i for all s ≥ ŝ.Now we can prove Proposition 4.3.

=
b ∈ {0, 1} and c-agreement has been reached, letting them finalize the component in at most 2 more protocol steps.Moreover if they reach c-agreement over 0, this means that they agree on the same value O k,c to insert as c-th component of the list Θ (s) k .Once c-agreement is reached in step s, the honest players will finalize the c-th component either in step s + 1 or step s + 2 depending on whether b = 0 or b = 1.

Fig. 1
Fig. 1 Amount of data broadcast in the network (in MB) using Algorand or Cob with parameters h = 0.8 and n = 4000 in terms of the number of components , logarithmic scale in both axes.

Fig. 2
Fig. 2 Amount of data broadcast in the network (in MB) using Algorand or Cob with parameters h = 0.8 and n = 4000 in terms of the number of components , linear scale in both axes.
This means that the honest step 3 players start in agreement on the component c of the list v .They may not be in agreement on the list component O i,c , but this does not matter.In fact, during step 4 no honest player is able to finalize component c by collecting more than t H messages with v = 0, since |MP(3)| < t H .In the same way even if the honest players have received more than t H valid messages with v = 1 they will not finalize the component c because 4 − 1 ≡ 1 mod 3. Anyway, each honest step 4 player i has received all honest messages, hence more than t H advertising v i If the user k has built a certificate for Θ in step s, it means that k has received t H messages from step s − 2 and step s − 1 for Θ.In particular, k collected t H step s − 2 messages for 0 in every component c such that Θ c = ⊥.We will call I 0 = {c : Θ c = ⊥, 1 ≤ c ≤ m}.By the assumptions in Definition 2.4, no honest user has received at least t H messages from step s − 2 that sponsors 1 in a component c ∈ I 0 .This implies that all the honest players have sent in step s − 1 a message with 0 in each component c ∈ I 0 .This brings all the honest users in c-agreement on such components and it will keep holding in the following steps.We also know that the user k has received t H messages from step s − 1 for Θ.This means that k has received at least t H messages for 1 in every component c such that Θ c = ⊥.We will callI 1 = {c : Θ c = ⊥, 1 ≤ c ≤ m}.Again, by the assumptions in Definition 2.4, no honest user has received at least t H messages from step s − 1 that sponsor 0 in a component c ∈ I 1 .

Table 2
Weight of messages of each step in the corresponding phase of the Cob and Algorand protocols.See also Table1.
1,h,n,honest )] = n • 2 • 132 + E Alg steps hMultiplying this value by we obtain the amount of data broadcast in the network by the nodes to reach consensus on ambiguous events:E[weight(Alg ,h,n,honest )] = • n • 264 + 2 +