Byzantine Fault Tolerant Vector Consensus with Anonymous Proposals

02/26/2019 ∙ by Christian Cachin, et al. ∙ Universität Bern The University of Sydney 0

In this paper, we introduce the anonymous proposer vector consensus problem in which a set of processes decide on a vector of values, where each value is a proposal made anonymously by a single process. In a distributed survey, for example, a solution to anonymous proposer vector consensus allows non-faulty processes to put forward a potentially controversial opinion that is not tied to their identity. More specifically, a non-faulty process' proposal is indistinguishable from that of all non-faulty processes, even in the presence of timing attacks. We also define the anonymous all-to-all reliable broadcast problem which ensures the properties of reliable broadcast hold with the same anonymity guarantee. For each problem, we present a protocol that solves it in presence of Byzantine faults. Solving anonymous all-to-all reliable broadcast, Anonymous All-to-all Reliable Broadcast Protocol (AARBP) executes in two regular and one anonymous message delays with the same message complexity as n invocations of Bracha's reliable broadcast protocol. Solving anonymous proposer vector consensus, Anonymous Proposer Vector Consensus Protocol (AVCP) is a reduction to binary consensus which can terminate in three regular and one anonymous message delay.



There are no comments yet.


This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

The vector consensus problem [25, 4, 45] involves identified processes deciding on a vector of values, each of which was proposed by one process. By contrast to interactive consistency [39], a protocol solving vector consensus need not assume synchrony. Consider a distributed survey, where a group of mutually distrusting processes wish to exchange opinions about a given issue. With vector consensus alone, processes are inextricably tied to their opinion. When this is undesirable—in whistle-blowing and electronic voting, for example—it is of interest to allow processes to anonymously propose their value. Importantly, using vector consensus for an election allows the contents of a proposal (vote) to be arbitrary. In voting for a leader, say, if the pool of candidates is sufficiently large—a population, say—the viable decentralised alternative, homomorphic tallying [21, 2], becomes infeasible, as votes must be encoded as values that can be meaningfully summed prior to decryption.

Motivated by this, we define the anonymous proposer vector consensus

problem, which extends vector consensus by asserting that all non-faulty processes cannot be associated with their proposal with probability greater than random guessing. We define

anonymous all-to-all reliable broadcast analogously with respect to reliable broadcast [11]. Our primary contribution, Anonymous Proposer Vector Consensus Protocol (AVCP), relies on a solution to anonymous all-to-all reliable broadcast, Anonymous All-to-all Reliable Broadcast Protocol (AARBP). Both protocols are correct in the presence of Byzantine faults. We also show that by composing AVCP and threshold encryption [22, 53], the contents of all non-faulty processes’ proposals can remain hidden until after AVCP terminates, which enables a form of electronic voting. In contexts where individual proposals (votes) can be eventually made public, this privacy guarantee can suffice. One promising application is in a replicated state machine with an appropriate mechanism for reconfiguration [38], such as a consortium blockchain [57], for governing the addition and removal of decider processes.

To achieve anonymity, we combine traceable ring signatures [29], which enable processes to anonymously prove their membership in a set of processes, and anonymous communication channels. Critically, the signatures expose a signer’s identity if and only if they sign two different messages, ensuring a process can only propose a single value to the consensus. Particularly because our protocols rely on both anonymous and regular channels, latency [3] and message transmission ordering [48] can diminish the anonymity provided by the anonymous channels themselves. To cope, we assume non-faulty processes anonymously broadcast their message after any previous instance of AVCP terminates, and that every process delivers these messages in a random order. To cope, we assume that processes anonymously broadcast in a window of synchrony and that messages that are anonymously sent are delivered to processes in a random order. These measures ensure that, in the view of the adversary, each message received by a process under their control could have been sent by any non-faulty process. The synchrony assumption can also allow more than proposals to be decided in vector consensus, which is useful in electronic voting. For efficiency and to reduce the impact of correlation-based attacks [42] in practice, processes anonymously broadcast once in a given protocol execution.

AVCP is an efficient reduction to a partially-synchronous binary consensus protocol [20], possibly terminating after three regular and one anonymous message delays. AARBP terminates after two regular and one anonymous message delays in general and has identical message complexity to instances of Bracha’s seminal reliable broadcast protocol [9]. In constructing AVCP, we demonstrate that AARBP can be used as a primitive in other protocols. Our experimental results are promising—with 100 geo-distributed nodes, AVCP generally terminated in less than ten seconds.

Related work. A protocol that solves the anonymous consensus problem [33] involves a set of processes without identifiers reaching consensus. Anonymous consensus protocols tolerating crash failures under asynchrony [8] and tolerating Byzantine failures under synchrony [46] have been proposed. Our goal is different in that processes with identifiers aim at reaching consensus by proposing their value anonymously. Anonymous channels can be instantiated using publicly-deployed [24, 59] networks, which have varying guarantees [30, 44]. In-house solutions that do not require additional processes [18, 32] and that are robust [31, 37] can also be used.

Consensus protocols, including AVCP (and excluding failure detector-based solutions [4]), can be constructed to accept proposals satisfying some notion of validity even if proposed by Byzantine processes [20, 13]. For example, a Byzantine process may propose a well-formed ballot in a decentralised electronic election. We have avoided leader-based protocol design [16] due to expensive view-change and the ability for a leader to support and exclude proposals with great freedom. Randomisation [47, 14, 43] could be used to avoid the reliance on the weak coordinator in DBFT [20], although ensues cryptographic overhead. A limited number of protocols solving vector consensus in the literature have been proposed, including those involving failure detectors [25, 4], wormholes [45] and explicit partial synchrony [19]. A reduction to binary consensus has been used in solving similar problems to vector consensus [6, 23, 20].

To ensure both anonymity and that processes only propose one value, linkable ring signatures [40], which can be more efficient in size [55] and computational effort [41] than traceable ring signatures, can be used, although traceability ensures that Byzantine processes are held accountable when double-signing. Systems that ensure anonymity amongst a distributed set of users that rely on blind signatures [17] can be constructed [15], but, unlike our protocols, rely on a trusted authority beyond the initial setup. Relevant cryptocurrencies that preserve the privacy of individual transactions, rather than that of consensus participants, include Monero [54] and Zcash [36].

Roadmap. The paper is structured as follows. Section 2 provides preliminary definitions and establishes the system model for our protocols. Section 3 explores anonymous all-to-all reliable broadcast and presents AARBP. Section 4 explores anonymous proposer vector consensus and presents AVCP. For simplicity, we present AARBP and AVCP in Sections 3 and 4 without considering anonymity in the presence of timing attacks, which we consider in Section 5. Finally, Section 6 concludes and proposes directions for future research. Appendices A, B and C contain the correctness proof of AARBP, a description of the binary consensus algorithm which AVCP relies on [20], and the correctness proof of AVCP, respectively. Appendix D combines AVCP and threshold encryption and characterises the resulting voting scheme. Appendix E provides empirical evaluations of our protocols on up to 100 nodes distributed on three continents.

2 Model and preliminaries

We assume the existence of a set of processes (where , and the th process is ), an adversary who corrupts up to processes in , and a trusted dealer . We work in the authenticated model, where cryptographic primitives are unbreakable by assumption. With concrete primitives, each party could be modelled as being able to execute a number of instructions bounded by a polynomial in a security parameter .

Network: We assume that consists of asynchronous, sequential processes that communicate over reliable, point-to-point channels in an asynchronous network. An asynchronous process is one that executes instructions at its own pace. We note that sequential processes may multiplex instruction execution. An asynchronous network is one where message delays are unbounded. A reliable network is such that any message sent will eventually be delivered by the intended recipient. We assume that processes can also communicate using one-way anonymous channels. In these, the identity of the sending process, who may not even be a member of , is unknown to the recipient.

Since consensus is impossible in the general case in failure-prone asynchronous message-passing systems [27], we assume partial synchrony holds among processes in to reach consensus in Section 4. That is, we assume there exists a point in time in protocol execution, the global stabilisation time (GST), after which all message transfer delays are upper bounded by an (unknown) finite constant [26]. To mitigate de-anonymisation attacks based on message delivery timing, we require both an additional synchrony assumption and an assumption on the order of anonymous message delivery being random. Both assumptions, and the motivation behind them, are described in Section 5.

Each process is equipped with the primitive “ to ”, which sends the message (possibly a tuple) to process . For simplicity, we assume that can send a message to itself. A process receives a message by invoking the primitive “”. Each process may invoke “ ”, which is short-hand for “for each do to end for”. Analogously, processes may invoke “ to ” and “ ”, which refers to the sending and broadcast of message , respectively, over anonymous channels. A process receives a message sent via a “” call by invoking the primitive “”.

Adversary: We assume that the adversary schedules message delivery over the reliable channels. For each call made, determines when the corresponding call is invoked. A portion of processes—up to members of —may be initially corrupted by and therefore exhibit Byzantine faults [39] over the lifetime of a protocol’s execution. That is, they may deviate from the predefined protocol in an arbitrary way. We assume can see all computations and messages sent and received by corrupted processes. We assume processes can only be corrupted by the adversary. A non-faulty process is one that is not corrupted by and therefore follows the prescribed protocol. cannot observe and calls made by non-faulty processes. cannot see the (local) computations that non-faulty processes perform.

Trusted setup: We assume an initial trusted setup, in which the trusted dealer, , generates the initial state for . In practice, generates keying material for cryptographic primitives.

Performance: For protocol analysis, we consider message complexity, the number of messages sent by non-faulty processes, and communication complexity or bit complexity, the number of bits transferred. We consider worst-case complexity as well as fault-free complexity, which is defined as the complexity when no process acts faulty.

Traceable ring signatures.

Informally, a ring signature [50, 29] allows a process to produce a signature that verifies its membership with respect to an ad-hoc set of public keys without revealing its identity. Variant schemes with weakened anonymity levels [40, 29] allows two messages signed by the same process to be linked or traced together. While linking does not reveal the signer’s identity, tracing does.

Hereafter, we consider traceable ring signatures (or TRSs), which are ring signatures that provide a traceability guarantee. To increase flexibility, we can consider traceability with respect to a particular string called an issue. Issue-dependent traceability [56] allows signers to maintain anonymity if they sign multiple messages, provided each message is signed with respect to a different issue. Our definitions are analogous to those of Fujisaki and Suzuki [29].

Let , which we denote as a tag. With respect to these definitions, we assume that all processes may query an idealised distributed oracle, which implements the following four operations:

  1. [noitemsep,topsep=5pt,parsep=2pt,partopsep=5pt,itemindent=1em,listparindent=1em,leftmargin=1em]

  2. , which takes the integer , tag and message , and outputs the signature . We restrict such that only process may invoke with first argument .

  3. , which takes the tag , message , and signature , and outputs a bit . All processes may query .

  4. , which takes the tag , messages and signatures , and outputs (possibly corresponding to a process ). All processes may query .

  5. takes a tag , a message , and a signature , and outputs a value . may not be called by any party, and exists only for protocol definitions.

We describe the behaviour of the idealised distributed oracle:

  • [noitemsep,topsep=5pt,parsep=2pt,partopsep=5pt,itemindent=1em,listparindent=1em,leftmargin=1em]

  • Signature correctness and unforgeability: there exists some process that previously invoked and obtained as a response. Unforgeability is captured by the “” claim.

  • Traceability and entrapment-freeness: The function behaves as defined below and :

    Traceability is captured by the “” claim: if , then the messages are linked, otherwise, the identity of the signing process is exposed. Entrapment-freeness is captured by the “” claim: loosely, processes cannot be falsely accused of double-signing.

  • Signature anonymity: Suppose , where is non-faulty. Then, it is impossible for the adversary to determine the value of with probability greater than .

With respect to , is output if and only if is the result of process having previously queried . The unforgeability property implies signature uniqueness: If calls and are made, then . The concrete scheme proposed by Fujisaki and Suzuki [29] satisfies these properties in the random oracle model [5] provided the Decisional Diffie-Hellman problem is intractable. It has signatures of size , where is the security parameter. To simplify the presentation, we assume that its properties hold unconditionally in the following. In implementation, Fujisaki and Suzuki’s scheme [29] requires , where denotes the th process’ public key, and is a string.

3 Anonymous all-to-all reliable broadcast

To reach eventual agreement in the presence of Byzantine processes without revealing who proposes what, we introduce the anonymous all-to-all reliable broadcast problem that preserves the anonymity of each honest sender reliably broadcasting. In this primitive, all processes are assumed to (anonymously) broadcast a message, and all processes receive a set of messages. It ensures that all honest processes always receive the same message from one specific sender while hiding the identity of any non-faulty sender. To solve this problem when , we propose the Anonymous All-to-all Reliable Broadcast Protocol (AARBP) that combines (i) Bracha’s reliable broadcast protocol [9] to guarantee that non-faulty processes eventually receive the same messages, (ii) Fujisaki and Suzuki’s traceable ring signature scheme [29] to hold processes accountable if they attempt to propose twice and (iii) a regular broadcast via anonymous channels. We analyse its complexity and discuss some optimisations, but defer the analysis to Appendix A.

Let be a message, and a signature, where the identifier identifies a given instance of AARB-broadcast. Each process is equipped with two operations, “” and “”. is invoked once with respect to , denoting the beginning of a process’ execution of AARBP with respect to . is invoked between and times throughout protocol execution. When a process invokes , they are said to “AARB-deliver” with respect to .

Then, given , we define a protocol that implements anonymous all-to-all reliable broadcast (AARB-broadcast) with respect to an identifier that uniquely defines an instance of AARB-broadcast as satisfying the following six properties:

  1. [noitemsep,topsep=5pt,parsep=2pt,partopsep=5pt,itemindent=1em,listparindent=1em,leftmargin=1em]

  2. AARB-Signing: If a non-faulty process AARB-delivers a message, then it must be of the form , where a process invoked .

  3. AARB-Validity: Suppose that a non-faulty process AARB-delivers . Let denote the output of an idealised call to . Then if is non-faulty, must have anonymously broadcast .

  4. AARB-Unicity: Consider any point of time in which a non-faulty process has AARB-delivered more than one tuple. Let , where , denote the set of these tuples. For each , let denote the output of an idealised call to . Then for all distinct pairs of tuples , .

  5. AARB-Termination-1: If a process is non-faulty and invokes , all the non-faulty processes eventually AARB-deliver , where .

  6. ARB-Termination-2: If a non-faulty process AARB-delivers , then all the non-faulty processes eventually AARB-deliver .

We require AARB-Signing to ensure that the other properties are meaningful. Since messages are anonymously broadcast, properties refer to the index of the signing process determined by an idealised call to . In spirit, AARB-Validity ensures if a non-faulty process AARB-delivers a message that was signed by a non-faulty process , then must have invoked AARBP. Similarly, AARB-Unicity ensures that a non-faulty process will AARB-deliver at most one message signed by each process. We note that AARB-Termination-2 is critical for consensus, as without it, different processes may AARB-deliver different messages produced by the same process, as in the two-step algorithm implementing no-duplicity broadcast [10, 49]. Finally, we state the anonymity property:

  1. [noitemsep,topsep=10pt,parsep=2pt,partopsep=10pt,itemindent=1em,listparindent=1em,leftmargin=1em]

  2. AARB-Anonymity: Let be a tuple anonymously broadcast by a non-faulty process . Then, it is impossible for the adversary to determine the value of with probability .

Informally, AARB-Anonymity guarantees that the source of an anonymously broadcast message by a non-faulty process is unknown to the adversary, in that it is indistinguishable from (non-faulty) processes.

State and messages.

Each process in begins with two empty buffers: , corresponding to messages that they may AARB-deliver, and , corresponding to all messages that they have AARB-delivered. Each process also tracks , which uniquely identifies an instance of AARB-broadcast. For a given instance of AARBP identified by , all messages sent by non-faulty processes must contain . Similarly, messages must contain one of three headers: INIT, corresponding to the initial broadcast of a process’ proposal, ECHO, corresponding to an acknowledgement of the INIT message, or READY, corresponding to an acknowledgement that enough processes have received the message to ensure eventual, safe AARB-delivery.

Initial State
1: Buffer of messages
2: Delivered messages
3: Identifier for the instance of AARB-broadcast
7:initial receipt of INIT
9:if  then
10:      for each  do
11:            if  “indep” then
12:                  Double-signing detected
13:                 break
14:            end if
15:      end for
17:      if  then
18:             ECHO
19:      end if
20:end ifreceipt ECHO from processes
21:if READY not yet broadcast then
22:       READY
23:end if
24:receipt READY from processes
25:if READY not yet broadcast then
26:       READY
27:end if
28:receipt READY from processes
29:if  then
33:end if
Algorithm 1 AARBP

We now present AARBP (Algorithm 1). To begin, each process broadcasts INIT over anonymous channels (line 6), where . Upon first receipt of each message of the form INIT, a process checks the following (line 7):

  • [noitemsep,topsep=5pt,parsep=2pt,partopsep=5pt,itemindent=1em,listparindent=1em,leftmargin=1em]

  • Whether the signature is well-formed as per , verifying the signer’s membership in (line 8).

  • Whether any message in is not independent from via , ensuring AARB-Unicity as is discarded if double-signing is detected (lines 10 to 15).

Then, given that passes the above checks, ECHO is broadcast (line 18). Note that this broadcast, and all subsequent broadcasts with respect to , are performed over regular (reliable, non-anonymous) channels of communication. To mitigate de-anonymisation, the signer of performs the same message processing and message propagation as all other non-faulty processes.

The rest of the protocol proceeds as per Bracha’s reliable broadcast [9]: If processes receive ECHO from more than different processes, they broadcast READY (lines 2022). If processes receive READY from different processes, they broadcast READY if not yet done (lines 2426). This ensures convergence and implies that at least one non-faulty process must have sent READY to the receiving process. Once processes have received READY from different processes, they AARB-deliver with respect to if not yet done (line 32). At this point, at least non-faulty processes must have broadcast READY. Thus, all non-faulty processes will eventually propagate READY.


Whilst Bracha’s protocol [9] requires three message steps to converge, AARBP requires an initial, anonymous message step and two (regular) message steps. Both AARBP and invocations of Bracha’s protocol have a message complexity of . If we consider unsigned messages to be of size , then each message propagated in AARBP is of size , the size of a traceable ring signature as in [29]. Thus, the bit complexity of all-to-all AARBP is (as opposed to in all-to-all reliable broadcast [9]). To reduce the bit complexity when some messages are delivered in order, we can hash ECHO and READY messages [13]. Consequently, communication complexity can be reduced to .

We consider cryptographic overhead as if Fujisaki and Suzuki’s TRS scheme [29] were used. In AARBP, each process signs one message ( work), verifies up to messages ( work), and perform tracing upon receipt of each INIT message (up to ). Naively, tracing signatures pairwise requires operations, and so processes have to perform work. This can be sped up by populating a hash table with the individual values of each tag as defined in [29]. Thus, processes can perform expected lookups per tuple , requiring expected work tracing overall.

4 Anonymous proposer vector consensus

In this section, we introduce the anonymous proposer vector consensus problem and present and discuss the protocol Anonymous Proposer Vector Consensus Protocol (AVCP) that solves it. We defer its proof to Appendix C. The anonymous proposer vector consensus problem brings anonymity to the vector consensus problem [25] where non-faulty processes reach an agreement upon a vector containing at least proposed values. More precisely, the anonymous proposer vector consensus ensures that a process’ proposal is indistinguishable from that of all non-faulty processes. In electronic voting, this provides a natural mechanism to prevent double-voting and enforce election eligibility requirements. Each process is equipped with two operations. Firstly, “” begins execution of an instance of AVCP with respect to the identifier and proposal . Secondly, “” denotes the output of from an instance of consensus, and is invoked exactly once with respect to . We define a protocol that solves anonymous vector consensus with respect to these operations as satisfying the following four properties:

  1. [noitemsep,topsep=5pt,parsep=2pt,partopsep=5pt,itemindent=1em,listparindent=1em,leftmargin=1em]

  2. AVC-Anonymity: Suppose that is proposed by a non-faulty process . Then, it is impossible for the adversary to determine the value of with probability .

It also requires the original agreement and termination properties of vector consensus to be ensured:

  1. [noitemsep,topsep=5pt,parsep=2pt,partopsep=5pt,itemindent=1em,listparindent=1em,leftmargin=1em]

  2. AVC-Agreement: All non-faulty processes that decide output the same vector .

  3. AVC-Termination: Every non-faulty process eventually decides on a vector of proposals.

It also requires a validity property that depends on a pre-determined, deterministic validity predicate  [13, 20] which we assume is common to all processes. We assume that all non-faulty processes propose a value that satisfies .

  1. [noitemsep,topsep=5pt,parsep=2pt,partopsep=5pt,itemindent=1em,listparindent=1em,leftmargin=1em]

  2. AVC-Validity: Consider each non-faulty process. Each value that is decided must satisfy , and . Further, at least values correspond to the proposals of distinct non-faulty processes.


A simple protocol solving anonymous proposer vector consensus may be designed as follows: (i) Every process anonymously broadcasts (or sends to a leader) a message which is signed with a traceable ring signature; (ii) each process (or a leader) waits for the receipt of messages that satisfy ; (iii) processes perform multivalued (or vector) consensus with respect to their delivered, valid messages. Using a leader-based algorithm like PBFT [16] in step (iii) would enable the leader to impose any valid values onto . In particular, the leader may deliberately include values from a corrupt coalition and exclude other values. Using DBFT [20] directly would largely alleviate this issue, although would incur an additional message step and unduly increase communication complexity, since every TRS is of size (thus every proposal is of size ).

In contrast, we present a reduction which may converge in three message steps and one anonymous message step, by comparison to four message steps as in DBFT, and is similarly efficient in message complexity. The protocol is divided into two components. Firstly, the reduction component (Algorithm 2) reduces anonymous proposer vector consensus to binary consensus. It is similar to DBFT [20], which in turn is similar to Ben-Or et al.’s [6], in which instances of reliable broadcast and binary consensus are executed. But, since proposals are made anonymously, processes cannot associate proposals with binary consensus instances a priori. Consequently, processes start with unlabelled binary consensus instances, and label them over time with the hash digest of proposals they deliver (of the form ). To cope with messages sent and received in unlabelled binary consensus instances, we require a handler component (Algorithm 3) that replaces function calls made in binary consensus instances.


In addition to the communication primitives detailed in Section 2 and the two primitives “” and “”, the following primitives may be called: “”, where is an instance of binary consensus and , begins execution of with initial value , “” and “”, as in Section 3, “” as described above, “” (resp. “”), which returns the keys (resp. values) of a map , “”, which returns the key of in a map , “”, which removes and returns a value from set , and “”, a collision-resistant hash function which returns based on .


Each process tracks the following variables: , a common identifier for a given instance of AVCP. , which maps labels of the form to AARB-delivered messages of the form that may be decided, and is initially empty. , tracking the number of binary consensus instances for which a decision has been reached, initialised to 0. , the set of proposals for which 1 was decided in the corresponding binary consensus instance, initialised to . , which maps labels, which are the hash digest of AARB-delivered proposals, to binary consensus instances, and is initially empty. , a set of binary consensus instances (initially of cardinality ) with no current label. , which maps two keys, EST and AUX, to maps with integer keys which map to a set of labels, all of which are initially empty. , which maps two keys, EST and AUX, to maps with integer keys which map to an integer , all of which are initially empty.


In addition to messages propagated in AARBP, non-faulty processes process messages of the form TAG, where TAG EST AUX, , and . A process buffers a message TAG until labels an instance of binary consensus , at which point it is considered receipt in . The handler, described below, ensures that all messages sent by non-faulty processes eventually correspond to a label in their set . Similarly, a process can only broadcast such a message after labelling the corresponding instance of binary consensus. Processes also process messages of the form TAG, where TAG EST_ONES AUX_ONES, , and is a set of strings corresponding to binary consensus instance labels.

2:for each s.t. not yet invoked do
3:      Invoke
4:end for
6:invocation of
8:if  then deterministic, common validity function
10:      Invoke if not yet invoked
11:end if
12: deciding a value , where
13:if  then
15:end if
Algorithm 2 AVCP (1 of 2): Reduction to binary consensus

In the reduction, (initially unlabelled) instances of binary consensus are used, each corresponding to a value that one process in may propose. Each (non-faulty) process invokes AARBP with respect to and their value (line 1), anonymously broadcasting . On AARB-delivery of some message , an unlabelled instance of binary consensus is deposited into , whose key (label) is set to (line 7). Proposals that fulfil are stored in (line 9), and is invoked with respect to the newly labelled instance if not yet done (line 10). Upon termination of each instance (line 12), provided 1 was decided, the corresponding proposal is added to (line 14). For either decision value, is incremented (line 16). Once 1 has been decided in instances of binary consensus, processes will propose 0 in all instances that they have not yet proposed in (line 3). Note that upon AARB-delivery of valid messages after this point, is not invoked at line 10. Upon the termination of all instances of binary consensus (after line 4), all non-faulty processes decide their set of values for which 1 was decided in the corresponding instance of binary consensus (line 5).

invoking “EST” (line 16in Algorithm 4) in
18:      if b = 1 then
19:             EST
20:            ESTEST
21:      end if
22:      ESTEST
23:      if ESTEST then
24:             EST_ONESEST
25:      end ifinvoking “ AUX” (line 5 in Algorithm 4) in
27:      if b = 1 then
28:             AUX
29:            AUXAUX
30:      end if
31:      AUXAUX
32:      if AUXAUX then
33:             AUX_ONESAUX
34:      end ifreceipt of TAG, where
36:      if TAG  EST_ONES then
37:            TEMP  EST
38:      else TEMP  AUX
39:      end if
40:      for each such that  do
41:            deliver TEMP in
42:      end for
43:      for each  do
44:            deliver TEMP in
45:      end for
Algorithm 3 AVCP (2 of 2): Handler

As proposals are anonymously broadcast, binary consensus instances cannot be associated with process identifiers a priori, and so are labelled by AARB-delivered messages. Thus, we require the handler, which overrides two of the three calls in the non-terminating variant of the binary consensus of [20] (Algorithm 4). We defer the reader to Appendix B for a description of the non-terminating algorithm, and the components of the terminating variant that require handling.

We now describe the handler (Algorithm 3). Let be an instance of binary consensus. On calling () (and at the beginning of each round ), processes invoke BV-broadcast (line 4 of Algorithm 4), immediately calling “broadcast EST” (line 16 of Algorithm 4). If , EST is broadcast, and is added to the set EST (line 20). Note that, given AARB-Termination-2, all messages sent by non-faulty processes of the form EST will be deposited in an instance labelled by . Then, as the binary consensus routine terminates when all non-faulty processes propose the same value, all processes will decide the value 1 in instances of binary consensus (i.e. will pass line 1), after which they execute in the remaining instances of binary consensus.

Since these instances may not be labelled when a process wishes to broadcast a value of the form EST, we defer their broadcast until “ EST” is called in all instances of binary consensus. At this point (line 23), EST_ONES is broadcast (line 24). A message of the form EST_ONES is interpreted as the receipt of zeros in all instances not labelled by elements in (at lines 41 and 44). This can only be done once all elements of label instances of binary consensus (i.e., after line 35). Note that if EST, then there are no zeroes to be processed by receiving processes, and so the broadcast at line 24 can be skipped.

Handling “ AUX” calls (line 5 of Algorithm 4) is identical to the handling of initial “ EST” calls. Note that the third broadcast in the original algorithm, where EST is broadcast upon receipt from processes if not yet done before (line 17 of Algorithm 4 (BV-Broadcast)), can only occur once the corresponding instance of binary consensus is labelled. Thus, it does not need to be handled. From here, we can see that messages in the handler are processed as if instances of the original binary consensus algorithm were executing.

Complexity and optimizations.
Complexity AVCP DBFT
Fault-free message complexity
Worst-case message complexity
Fault-free bit complexity
Worst-case bit complexity
Table 1: Comparing the complexity of AVCP and DBFT [20] after GST [26]

Let be a security parameter, and the size of a message digest. We compare the message and communication complexity of AVCP with DBFT [20], which, as written, can be easily altered to solve vector consensus. We assume that AVCP is invoking the terminating variant of the binary consensus of [20]. When considering complexity, we only count messages in the binary consensus routines once the global stabilisation time (GST) has been reached [26]. Both fault-free and worst-case message complexity are identical between the two protocols. We remark that there exist runs of AVCP where processes are faulty with message complexity, such as when a process has crashed. In terms of communication complexity, AVCP is moderately more expensive due to the size of traceable ring signatures (). Given TRS’s of size [28] are instead used, fault-free and worst-case communication complexities for AVCP become and respectively.

As is done in DBFT [20], we can combine the anonymous all-to-all reliable broadcast of a message and the proposal of a 1 in the first round of a binary consensus instance. To this end, a process may skip the BV-broadcast step in round 1, which may allow AVCP to converge in three message steps and one anonymous message step.

It may be useful to invoke “ TAG”, where TAG ESTAUX (lines 19 and 28) when the instance of binary consensus is labelled, rather than simply when (i.e., the condition preceding these calls). Since it may take some time for all instances of binary consensus to synchronise, doing this may speed up convergence in the “faster” instances. However, messages of the form TAG, where TAG EST_ONES AUX_ONES, would then often contain a larger set.

5 Anonymity in the presence of timing attacks

In our model, there are two modes of adversarial behaviour that can de-anonymise a non-faulty process in our protocols: (i) The adversary observes message transmission time between processes [3]. For example, suppose that the time taken for a process to transmit a message to all other processes in takes much longer than message transmission time between all other processes. Without additional assumptions, the adversary can often deduce ’s identity with respect to its proposal. (ii) The adversary observes messages that different processes send [48]. Consider an application where a process does not participate in an instance of consensus until the previous instance (if it exists) has terminated. Suppose in an instance of consensus that processes have anonymously broadcast their proposals, which have been delivered to some process, but a process is still participating in the previous instance of consensus. The adversary can observe this, and can thus de-anonymise on receipt of its proposal. To cope with these attack vectors, we posit two conditions:

  1. [noitemsep,topsep=5pt,parsep=2pt,partopsep=5pt,itemindent=1em,listparindent=1em,leftmargin=1em]

  2. The order in which a process delivers a message anonymously broadcast is random among non-faulty processes. This mitigates attacks as in “(i)”.

  3. After an instance of consensus terminates, a non-faulty process waits on a local timeout for time before starting the next instance of consensus. is set such that processes are sufficiently synchronised so that the slowest process terminates after the fastest (non-faulty) process starts the next instance of consensus. This mitigates attacks as in “(ii)”.

In practice, satisfying these conditions is feasible. To achieve condition 1, we assume first that messages anonymously broadcast by non-faulty processes are delivered in a random order to each process. By assuming that the time period over which these messages are delivered is sufficiently large (larger than ), and processes execute in a sufficiently timely manner, condition 1 should with high probability. For condition 2, recall that if a process decides in round in an instance of binary consensus, then all non-faulty processes will decide by round

. We can use this fact, and measurements of message transmission time, to estimate an appropriate value


We remark that under general sequential composition where an instance may only execute after another has terminated, both conditions are required. But, if all instances of AARBP/AVCP are unrelated in the sense that their execution (a process’ input, when a process can start execution) does not depend on any other instance, then only condition 1 is required to ensure anonymity. We show that AARBP and AVCP satisfy their respective anonymity definitions in Appendices A and C.

6 Conclusion

In this paper, we have presented modular and efficient distributed protocols which allow identified processes to propose values anonymously. In the context of our protocols, we have proposed a model for achieving anonymity. In terms of future work, it is of interest to evaluate anonymity in different formal models [51, 34] and with respect to various practical attack vectors [48]. Further, a reduction to a randomized [14] binary consensus algorithm would remove the dependency on the weak coordinator in the binary consensus algorithm we rely on [20].


This research is in part supported under Australian Research Council Discovery Projects funding scheme (project number 180104030) entitled ‘’Taipan: A Blockchain with Democratic Consensus and Validated Contracts”. Vincent Gramoli is a Future Fellow of the Australian Research Council.



  • [1] The ristretto group., 2018. Accessed: 2018-11-03.
  • [2] Ben Adida. Helios: Web-based open-audit voting. In Proceedings of the 17th Conference on Security Symposium, SS’08, pages 335–348, Berkeley, CA, USA, 2008. USENIX Association.
  • [3] Adam Back, Ulf Möller, and Anton Stiglic. Traffic analysis attacks and trade-offs in anonymity providing systems. In International Workshop on Information Hiding, pages 245–257. Springer, 2001.
  • [4] Roberto Baldoni, Jean-Michel Hélary, Michel Raynal, and Lenaik Tangui. Consensus in byzantine asynchronous systems. Journal of Discrete Algorithms, 1(2):185–210, 2003.
  • [5] Mihir Bellare and Phillip Rogaway. Random oracles are practical: A paradigm for designing efficient protocols. In Proceedings of the 1st ACM conference on Computer and communications security, pages 62–73. ACM, 1993.
  • [6] Michael Ben-Or, Boaz Kelmer, and Tal Rabin. Asynchronous secure computations with optimal resilience (extended abstract). In Proceedings of the Thirteenth Annual ACM Symposium on Principles of Distributed Computing, PODC ’94, pages 183–192, New York, NY, USA, 1994. ACM.
  • [7] Daniel J Bernstein. Curve25519: new diffie-hellman speed records. In International Workshop on Public Key Cryptography, pages 207–228. Springer, 2006.
  • [8] François Bonnet and Michel Raynal. The price of anonymity: Optimal consensus despite asynchrony, crash and anonymity. In International Symposium on Distributed Computing, pages 341–355. Springer, 2009.
  • [9] Gabriel Bracha. Asynchronous byzantine agreement protocols. Information and Computation, 75(2):130 – 143, 1987.
  • [10] Gabriel Bracha and Sam Toueg. Resilient consensus protocols. In Proceedings of the second annual ACM symposium on Principles of distributed computing, pages 12–26. ACM, 1983.
  • [11] Gabriel Bracha and Sam Toueg. Asynchronous consensus and broadcast protocols. Journal of the ACM (JACM), 32(4):824–840, 1985.
  • [12] Eric Brier and Marc Joye. Weierstraß elliptic curves and side-channel attacks. In International Workshop on Public Key Cryptography, pages 335–345. Springer, 2002.
  • [13] Christian Cachin, Klaus Kursawe, Frank Petzold, and Victor Shoup. Secure and efficient asynchronous broadcast protocols. In Advances in Cryptology - CRYPTO 2001, 21st Annual International Cryptology Conference, Santa Barbara, California, USA, August 19-23, 2001, Proceedings, pages 524–541, 2001.
  • [14] Christian Cachin, Klaus Kursawe, and Victor Shoup. Random oracles in Constantinople: Practical asynchronous Byzantine agreement using cryptography. Journal of Cryptology, 18(3):219–246, 2005.
  • [15] Jean Camp, Michael Harkavy, J. D. Tygar, and Bennet Yee. Anonymous atomic transactions. In In Proceedings of the 2nd USENIX Workshop on Electronic Commerce (Nov.), USENIX Assoc, 1996.
  • [16] Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance. In OSDI, volume 99, pages 173–186, 1999.
  • [17] David Chaum. Blind signatures for untraceable payments. In Advances in cryptology, pages 199–203. Springer, 1983.
  • [18] David Chaum. The dining cryptographers problem: Unconditional sender and recipient untraceability. Journal of cryptology, 1(1):65–75, 1988.
  • [19] Miguel Correia, Nuno Ferreira Neves, and Paulo Veríssimo. From consensus to atomic broadcast: Time-free byzantine-resistant protocols without signatures. The Computer Journal, 49(1):82–96, 2006.
  • [20] Tyler Crain, Vincent Gramoli, Mikel Larrea, and Michel Raynal. DBFT: Efficient Byzantine Consensus with a Weak Coordinator and its Application to Consortium Blockchains. ArXiv e-prints, February 2017.
  • [21] Ronald Cramer, Matthew Franklin, Berry Schoenmakers, and Moti Yung. Multi-authority secret-ballot elections with linear work. In International Conference on the Theory and Applications of Cryptographic Techniques, pages 72–83. Springer, 1996.
  • [22] Yvo Desmedt. Threshold cryptosystems. In International Workshop on the Theory and Application of Cryptographic Techniques, pages 1–14. Springer, 1992.
  • [23] Panos Diamantopoulos, Stathis Maneas, Christos Patsonakis, Nikos Chondros, and Mema Roussopoulos. Interactive consistency in practical, mostly-asynchronous systems. In Parallel and Distributed Systems (ICPADS), 2015 IEEE 21st International Conference on, pages 752–759. IEEE, 2015.
  • [24] Roger Dingledine, Nick Mathewson, and Paul Syverson. Tor: The second-generation onion router. In Proceedings of the 13th Conference on USENIX Security Symposium - Volume 13, SSYM’04, pages 21–21, Berkeley, CA, USA, 2004. USENIX Association.
  • [25] Assia Doudou and André Schiper. Muteness failure detectors for consensus with byzantine processes. Technical report, in Proceedings of the 17th ACM Symposium on Principle of Distributed Computing, (Puerto), 1997.
  • [26] Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. Consensus in the presence of partial synchrony. Journal of the ACM (JACM), 35(2):288–323, 1988.
  • [27] Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. Impossibility of distributed consensus with one faulty process. J. ACM, 32(2):374–382, April 1985.
  • [28] Eiichiro Fujisaki. Sub-linear size traceable ring signatures without random oracles. In IEICE Transactions on Fundamentals of Electronics Communications and Computer Sciences, volume E95.A, pages 393–415, 04 2011.
  • [29] Eiichiro Fujisaki and Koutarou Suzuki. Traceable ring signature. In Tatsuaki Okamoto and Xiaoyun Wang, editors, Public Key Cryptography – PKC 2007, pages 181–200, Berlin, Heidelberg, 2007. Springer Berlin Heidelberg.
  • [30] Yossi Gilad and Amir Herzberg. Spying in the dark: Tcp and tor traffic analysis. In Simone Fischer-Hübner and Matthew Wright, editors, Privacy Enhancing Technologies, pages 100–119, Berlin, Heidelberg, 2012. Springer Berlin Heidelberg.
  • [31] Philippe Golle, Markus Jakobsson, Ari Juels, and Paul Syverson. Universal re-encryption for mixnets. In Tatsuaki Okamoto, editor, Topics in Cryptology – CT-RSA 2004, pages 163–178, Berlin, Heidelberg, 2004. Springer Berlin Heidelberg.
  • [32] Philippe Golle and Ari Juels. Dining cryptographers revisited. In International Conference on the Theory and Applications of Cryptographic Techniques, pages 456–473. Springer, 2004.
  • [33] Rachid Guerraoui and Eric Ruppert. Anonymous and fault-tolerant shared-memory computing. Distributed Computing, 20(3):165–177, 2007.
  • [34] Joseph Y Halpern and Kevin R O’Neill. Anonymity and information hiding in multiagent systems. Journal of Computer Security, 13(3):483–514, 2005.
  • [35] Mike Hamburg. Decaf: Eliminating cofactors through point compression. In Annual Cryptology Conference, pages 705–723. Springer, 2015.
  • [36] Daira Hopwood, Sean Bowe, Taylor Hornby, and Nathan Wilcox. Zcash protocol specification. Technical report, 2016–1.10. Zerocoin Electric Coin Company, 2016.
  • [37] Markus Jakobsson. A practical mix. In International Conference on the Theory and Applications of Cryptographic Techniques, pages 448–461. Springer, 1998.
  • [38] Leslie Lamport, Dahlia Malkhi, and Lidong Zhou. Reconfiguring a state machine. SIGACT News, 41(1):63–73, 2010.
  • [39] Leslie Lamport, Robert Shostak, and Marshall Pease. The byzantine generals problem. ACM Transactions on Programming Languages and Systems (TOPLAS), 4(3):382–401, 1982.
  • [40] Joseph K. Liu, Victor K. Wei, and Duncan S. Wong. Linkable spontaneous anonymous group signature for ad hoc groups. In Huaxiong Wang, Josef Pieprzyk, and Vijay Varadharajan, editors, Information Security and Privacy, pages 325–335, Berlin, Heidelberg, 2004. Springer Berlin Heidelberg.
  • [41] Joseph K Liu and Duncan S Wong. Linkable ring signatures: Security models and new schemes. In International Conference on Computational Science and Its Applications, pages 614–623. Springer, 2005.
  • [42] Nick Mathewson and Roger Dingledine. Practical traffic analysis: Extending and resisting statistical disclosure. In International Workshop on Privacy Enhancing Technologies, pages 17–34. Springer, 2004.
  • [43] Achour Mostéfaoui, Hamouma Moumen, and Michel Raynal. Signature-free asynchronous binary byzantine consensus with , messages, and expected time. Journal of the ACM (JACM), 62(4):31, 2015.
  • [44] Steven J. Murdoch and George Danezis. Low-cost traffic analysis of tor. In Proceedings of the 2005 IEEE Symposium on Security and Privacy, SP ’05, pages 183–195, Washington, DC, USA, 2005. IEEE Computer Society.
  • [45] Nuno Ferreira Neves, Miguel Correia, and Paulo Verissimo. Solving vector consensus with a wormhole. IEEE Transactions on Parallel and Distributed Systems, 16(12):1120–1131, 2005.
  • [46] Michael Okun and Amnon Barak. Efficient algorithms for anonymous byzantine agreement. Theory of Computing Systems, 42(2):222–238, 2008.
  • [47] Michael O Rabin. Randomized byzantine generals. In Foundations of Computer Science, 1983., 24th Annual Symposium on, pages 403–409. IEEE, 1983.
  • [48] Jean-François Raymond. Traffic analysis: Protocols, attacks, design issues, and open problems. In Designing Privacy Enhancing Technologies, pages 10–29. Springer, 2001.
  • [49] Michel Raynal. Reliable Broadcast in the Presence of Byzantine Processes, pages 61–73. Springer International Publishing, Cham, 2018.
  • [50] Ronald L. Rivest, Adi Shamir, and Yael Tauman. How to leak a secret. In Colin Boyd, editor, Advances in Cryptology — ASIACRYPT 2001, pages 552–565, Berlin, Heidelberg, 2001. Springer Berlin Heidelberg.
  • [51] Andrei Serjantov and George Danezis. Towards an information theoretic metric for anonymity. In International Workshop on Privacy Enhancing Technologies, pages 41–53. Springer, 2002.
  • [52] Adi Shamir. How to share a secret. Commun. ACM, 22(11):612–613, November 1979.
  • [53] Victor Shoup and Rosario Gennaro. Securing threshold cryptosystems against chosen ciphertext attack. Journal of Cryptology, 15(2):75–96, Jan 2002.
  • [54] Shi-Feng Sun, Man Ho Au, Joseph K. Liu, and Tsz Hon Yuen. Ringct 2.0: A compact accumulator-based (linkable ring signature) protocol for blockchain cryptocurrency monero. In Simon N. Foley, Dieter Gollmann, and Einar Snekkenes, editors, Computer Security – ESORICS 2017, pages 456–474, Cham, 2017. Springer International Publishing.
  • [55] Patrick P. Tsang and Victor K. Wei. Short linkable ring signatures for e-voting, e-cash and attestation. In Robert H. Deng, Feng Bao, HweeHwa Pang, and Jianying Zhou, editors, Information Security Practice and Experience, pages 48–60, Berlin, Heidelberg, 2005. Springer Berlin Heidelberg.
  • [56] Patrick P. Tsang, Victor K. Wei, Tony K. Chan, Man Ho Au, Joseph K. Liu, and Duncan S. Wong. Separable linkable threshold ring signatures. In Anne Canteaut and Kapaleeswaran Viswanathan, editors, Progress in Cryptology - INDOCRYPT 2004, pages 384–398, Berlin, Heidelberg, 2005. Springer Berlin Heidelberg.
  • [57] Guillaume Vizier and Vincent Gramoli. Comchain: Bridging the gap between public and consortium blockchains. IEEE Blockchain, 18, 2018.
  • [58] Tsz Hon Yuen, Joseph K Liu, Man Ho Au, Willy Susilo, and Jianying Zhou. Efficient linkable and/or threshold ring signature without random oracles. The Computer Journal, 56(4):407–421, 2013.
  • [59] Bassam Zantout and Ramzi Haraty. I2p data communication system. In Proceedings of ICN, pages 401–409. Citeseer, 2011.

Appendix A Analysis of AARBP

In this appendix, we prove that all properties of anonymous reliable broadcast are fulfilled by our protocol, Anonymous All-to-all Reliable Broadcast Protocol (AARBP) (Algorithm 1 in Section 3).

Remark 1.

Let be positive integers s.t. . We have:

Thus, we refer to “ processes” and “more than processes” interchangeably.

Lemma A.1.

AARBP ensures AARB-Signing. That is, if a non-faulty process AARB-delivers a message, then it must be of the form , where a process invoked .


Suppose is non-faulty and AARB-delivers a message . We aim to show that , where was called by some process . For a non-faulty process to broadcast READY, they must have either received READY from different processes or ECHO from different processes. Since , there exists a non-faulty process that must have broadcast READY on receipt of ECHO from different processes to ensure that was AARB-delivered to any process. Similarly, since , there exists a non-faulty process that must have broadcast ECHO to ensure READY was broadcast by a non-faulty process. Process must have implicitly checked that and (at line 8). By signature unforgeability, implies that was called by some process . Thus, the property holds. ∎

Lemma A.2.

AARBP ensures AARB-Anonymity under the assumptions of the model (Section 2) and those made in Section 5. AARB-Anonymity is stated as follows. Let be a tuple anonymously broadcast by a non-faulty process . Then, it is impossible for the adversary to determine the value of with probability