One of the central components of any distributed system is a consensus protocol, by which the system’s participants can agree on its current state and use that information to take various actions; e.g., decide whether or not to accept a certain transaction as valid. At heart, many consensus protocols rely on a leader election protocol, in which one participant or subset of participants is chosen to lead these types of decisions for a single round (or set period of time). To elect a leader, participants must coordinate amongst themselves by exchanging several rounds of messages.
In settings such as those exemplified by distributed ledgers— and in particular by open blockchains such as Bitcoin— it is not clear how one could adopt traditional leader election protocols, as the desired level of decentralization amongst participants makes them appear inappropriate. As a result, the consensus protocol most often used in this setting is proof-of-work (PoW), which in some sense replaces the coordination costs of traditional protocols with the high computational cost of finding the partial pre-image of a hash, or solving some other cryptographic puzzle. Even in this seemingly leaderless consensus protocol, however, there is still an implicit notion of leadership, as the first participant to solve the puzzle effectively wins the authority to decide which transactions are accepted into the blockchain.
One natural area to explore in the setting of distributed ledgers is therefore the extent to which a compromise can be made between the coordination costs of traditional leader election protocols and the computational costs of PoW-based protocols, and indeed in recent years this has been an active area of research [24, 22, 14, 19, 6, 17, 35]. While some protocols attempt this compromise by inserting more traditional trust models and consensus protocols into the decentralized setting, others attempt to remove the computational cost of PoW without requiring any coordination costs. Instead, these consensus protocols replace the (explicit) investment of computational cost in PoW-based mining with some (implicit) represented investment in the health of the system on behalf of participants. As such, they are often referred to as proof-of-stake (PoS).
Given the lack of explicit computational cost, PoS-based protocols are subject to new types of attacks, and therefore careful and detailed analysis of both their leader election protocols— which, in contrast to PoW, must be made explicit— and their incentive mechanisms. While previous papers on PoS often try to solve both of these problems at once, in this paper we focus solely on the question of leader election. By addressing just this well defined question (‘how to securely agree on a leader without having to coordinate?’), we are able to model, analyze, and evaluate our proposed leader election protocol in a more rigorous manner than would be possible if trying to present a full PoS solution. We leave the incentives design for future work that requires a paper on its own.
With this in mind, we begin in Section 4 with a model for leader election protocols that is inspired by existing models for coin-tossing protocols but takes into account the unique requirements of a blockchain-based setting. In particular, we consider (1) liveness, which is an essential requirement for any distributed protocol; (2) fairness, as blockchains often rely on explicit incentives in the form of a reward when elected leader, so it is important to consider how often this happens and if it can be biased; and (3) different flavors of unpredictability, as if an adversary could predict either their own eligibility or that of another participant then it could launch attacks accordingly (in particular a grinding or a DoS attack, respectively).
Next, in Section 5 we present Caucus, our leader election protocol. Briefly, Caucus works by combining a source of private randomness (used to hide one’s eligibility from other participants until it is appropriate to reveal it) with a source of public randomness (used to guarantee fairness). To create the public randomness, we begin by looking to existing protocols for random beacons [34, 19, 11]. To create the private randomness, we simply allow each participant to do so themselves, and then ask them to publicly commit to it by revealing the head of a hash chain.
Our experiments in Section 6 highlight that even the cheapest random beacon we could find, SCRAPE , costs over $270 to generate in an on-chain Ethereum-based implementation, whereas a hybrid version that moves some computation off-chain costs under $80. This motivated us to create a random beacon inspired by RanDAO , that combines both public and private sources of randomness. This new solution relies on a somewhat stronger trust assumption (that at least one honest participant has contributed to the beacon) but costs only $0.10 per leader election. We also discuss in Section 7 how a leader election protocol like Caucus could be used to bootstrap from a PoW- to a PoS-based consensus protocol, although again we leave a detailed analysis of this problem and our solution as important future work, that requires an incentives model and analysis.
In summary, our paper makes the following concrete contributions:
We present the first model for leader election that is designed to capture the specific security requirements associated with blockchains;
We present a leader election protocol that, in addition to satisfying more traditional notions of security, ensures that leaders cannot be subject to DoS attacks because their eligibility is revealed ahead of time; and
We present Ethereum-based implementations of both our leader election protocol and its underlying random beacon that are cheap enough to be deployed today.
2 Related Work
The work that most closely resemble ours spans from leader election protocols in the distributed computing literature to more recent proof-of-stake proposals in the cryptography literature.
In the distributed systems literature, the leader election problem consists of picking one player (or processor) out of , considering that a fraction of them are bad (faulty or malicious). Most of the proposed solutions work in the full information model , where parties are computationally unbounded and every communication is broadcast. The first leader election protocol is due to Saks , who proposed a baton-passing algorithm resilient to a threshold of bad players. Since then, various protocols have improved on either the communication complexity or fraction of malicious players [3, 26, 30, 16, 21].
In the cryptography literature, a number of recent papers have proposed proof-of-stake protocols [19, 6, 17]. Briefly, some of the techniques are similar, but many of the proposals either rely solely on a source of global randomness (meaning they do not achieve as strong a notion of unpredictability), or do not use any global randomness (meaning they do not achieve as strong a notion of fairness). In the Snow White proof-of-stake protocol , the source of randomness is taken as some in a previous block in the blockchain, and the leader is then any participant with public key such that (where is some agreed-upon time). To ensure that all participants agree on the value of it must be sufficiently far back in the blockchain (in case of forks), which means the protocol does not satisfy any strong notion of unpredictability. Furthermore, is chosen by the participant who created this previous block, so as this value could have been biased by them it is also not possible to prove fairness.
The other main proposed protocol that does not explicitly rely on randomness generation is Algorand , whose solution in many ways resembles the RanDAO-inspired approach we describe in Section 5.3. In this protocol, a value is initialized randomly, and then for every round , a new value is defined as , where is a deterministic signature under the leader of round . Algorand does not specify, however, how could be initialized, saying just that it is “a random number, part of the system description, and thus publicly known.” This leaves open the possibility that whoever has set it may have again run a grinding attack to bias the protocol (even if doing so would be very computationally expensive). Again then, it is not clear how to prove fairness under the assumption that participants wouldn’t act to bias the protocol in their own favor (which seems economically rational). Another similar solution is presented in Ouroboros Praos . In this protocol, a random nonce is also initialized and then updated using a hash function applied to a Verifiable Random Function (VRF) using values from previous blocks. However their beacon can be manipulated by the adversary as a number of “resets” can be performed and thus it does not satisfy our security guarantees neither. To the best of our knowledge then, Caucus is the first implemented solution to achieve all security guarantees.
Finally, a related notion to the idea of leader election is that of generating public shared randomness [8, 34, 11]. While most existing protocols do not scale to hundreds or thousands of participants, recent work such as RandHound  (and its related RandShare and RandHerd protocols) work to achieve this goal. In Appendix A, we present the SCRAPE protocol , due to Cascudo and David, that we incorporate into Caucus as a way to initialize a random beacon.
3 Background Definitions and Notation
In this section, we present the underlying notation and cryptographic primitives we rely on in the rest of the paper. In particular, we begin with notation (Section 3.1), and then present definitions of hash functions (Section 3.2), and coin tossing (Section 3.3). We end with an overview of blockchains (Section 3.4), and in particular give definitions of proof-of-stake and some specific notation associated with the Ethereum platform.
If is a binary string then denotes its bit length. If is a finite set then denotes its size and denotes sampling a member uniformly from and assigning it to . denotes the security parameter and denotes its unary representation.
Algorithms are randomized unless explicitly noted otherwise. “PT” stands for “polynomial time.” By we denote running algorithm on inputs and random coins and assigning its output to . By we denote for sampled uniformly at random. By
we denote the set of values that have non-zero probability of being output byon inputs . Adversaries are algorithms. We denote non-interactive algorithms using the font , and denote interactive protocols using the font . We further denote such protocols as , where the -th entry of (respectively, ) is used to denote the input to (respectively, output of) the -th participant.
We say that two probability ensembles and are statistically close over a domain if is negligible; we denote this as .
3.2 Hash functions
A hash function is a function ; i.e., a function that maps strings of arbitrary length to strings of some fixed length . When a hash function is modeled as a random oracle, this means that computing is modeled as (1) looking up in some global map and using the value of if it has been set already, and (2) if not, picking a random value and setting in the map.
There are many desired properties of hash functions that trivially hold when they are modeled as random oracles. Of these, the two we are particularly interested in unpredictability and secrecy . These are defined as follows:
 A hash function satisfies unpredictability if no PT adversary can find an such that has some desired property. More formally, let be an oracle that, on queries , returns whether or not . Then for all , predicates , and PT adversaries that have access to , there exists an algorithm that has access only to such that has roughly the same advantage in predicting as does .
 A hash function satisfies secrecy if, given , no PT adversary with binary output can infer any information about . Formally, for a domain and for all ,
3.3 Coin tossing and random beacons
Coin tossing is closely related to leader election , and allows two or more parties to agree on a single or many random bits [7, 5, 28]; i.e., to output a value that is statistically close to random.
Let be the fraction of participants controlled by an adversary . Then a coin-tossing protocol satisfies -liveness if it is still possible to agree on a random value even in the face of such an .
A coin-tossing protocol satisfies unpredictability if, prior to some step in the protocol, no PT adversary can produce better than a random guess at the value of .
A coin-tossing protocol is -unbiasable if for all PT
adversaries controlling an fraction of participants, the
output is still statistically close to a uniformly distributed random
is still statistically close to a uniformly distributed random string.
Many coin-tossing protocols [7, 28] follow a structure called commit-then-reveal: to start, in the commit phase each participant creates and broadcasts a cryptographic commitment  to a random value. In the reveal phase, participants broadcasts the opening of their commitments, and can use the opening to check the validity of the initial commitment. The output value is then some combination (e.g., XOR) of all the individual random values. Intuitively, while this basic solution does not satisfy liveness, it satisfies unpredictability due to the hiding property of the commitment scheme (where corresponds to the step in which the last commitment is opened), and unbiasability due to the binding property. In order to achieve liveness, secret sharing can be used. To ensure that the protocol produces a valid output, participants create shares of their secret and send these shares to other participants during the commit phase. This allows participants to recover the value of another participant even if they abort.
A closely related concept to coin tossing is random beacons. These were first introduced by Rabin  as a service for “emitting at regularly spaced time intervals, randomly chosen integers”. To extend the above definitions to random beacons, as inspired by , we require that the properties of -liveness and -unbiasability apply for each iteration of the beacon, or round. We also require that the in the unpredictability definition is at least the begining of each round. We present such a scheme, SCRAPE , in more detail in Appendix A.
3.4 Blockchain basics
Distributed ledgers, or blockchains, have become increasingly popular ever since Bitcoin was first proposed by Satoshi Nakamoto in 2008 . Briefly, individual Bitcoin users wishing to pay other users broadcast transactions to a global peer-to-peer network, and the peers responsible for participating in Bitcoin’s consensus protocol (i.e., for deciding on a canonical ordering of transactions) are known as miners. In order to participate, miners form blocks, which contain (among other things that we ignore for ease of exposition) the transactions collected since the previous block was mined, which we denote , a pointer to the previous block hash , and a proof-of-work (PoW). This PoW is the solution to a computational puzzle specified by a value ; roughly, it is a value such that , and indicates that the miner has put in the computational effort (or work) necessary to find . Every other peer in the network can verify the validity of a block, and if future miners choose to include it by incorporating its hash into their own PoW then it becomes part of the global blockchain. In the rare case where two miners find a block at the same time, other miners decide which block to mine off of. Bitcoin follows the longest chain rule, meaning that whichever fork creates the longest chain is the one that is considered valid. The block that hasn’t been included in that fork is thus abandoned.
By its nature, PoW consumes a lot of energy. Thus, some alternative consensus protocols have been proposed that are more cost-effective; as of this writing, arguably the most popular of these is called proof-of-stake (PoS) [1, 20, 2, 35]. If we consider PoW to be a leader election protocol in which the leader (i.e., the miner with the valid block) is selected in proportion to their amount of computational power, then PoS can be seen as a leader election protocol in which the leader (i.e., the participant who is eligible to propose a new block) is selected in proportion to some “stake” they have in the system. This can be represented as the amount of coins they have (either in some form of escrow or just in total), or the age of their coins.
As security no longer stems from the fact that it is expensive to create a block, PoS poses several technical challenges . The main three are as follows: first, the nothing at stake problem says that have no reason to not mine on top of every chain, since mining is costless, so it is more difficult to reach consensus. This is an issue of incentives, so given our focus on leader election we consider it out of scope for this paper.
Second, PoS allows for grinding attacks, in which once a miner is elected leader they privately iterate through many valid blocks (again, because mining is costless) in an attempt to find one that may give them an unfair advantage in the future (e.g., make them more likely to be elected leader). This is an issue that we encounter in Section 5 and address using a public source of randomness.
Finally, in a long range attack, an attacker may bribe miners into selling their old private keys, which would allow them to re-write the entire history of the blockchain. Again, this is an issue of incentives that we consider out of the scope of this paper.
3.4.2 Smart contracts and Ethereum
Bitcoin’s scripting language is intentionally limited, and intended to support mainly the transfer of coins from one set of parties to another. In contrast, the Ethereum platform provides a more complex scripting language that allows it to act as a sort of distributed virtual machine, and to support more complex objects called smart contracts.
Ethereum transactions contain a destination address (that can specify either the location of a stateful smart contract, or just a regular user-owned address), an amount to be sent (denominated in ether), an optional data field , a gas limit, and a signature authorizing the transaction with respect to the sender’s keypair (just as in Bitcoin). We ignore everything except the field in our protocol specifications below and in Section 5, but mention briefly here that gas is a subcurrency in Ethereum used to pay for the computational operations performed by a smart contract. We denote the process of creating a transaction as (again, ignoring all but the field) , and the process of verifying a transaction as .
4 A Model for Leader Election
Most of the consensus protocols in the distributed systems literature are leader-based, as it is the most optimal solution in term of coordination . Perhaps as a result, leader election has in general been very well studied within the distributed systems community [31, 30, 16, 26, 21].
Nevertheless, to the best of our knowledge the problem of leader election has not been given an extensive cryptographic or security-focused treatment, so in this section we provide a threat model in which we consider a variety of adversarial behavior. This is particularly crucial in open applications like consensus protocols for blockchains, as any actor can participate in the consensus protocol, so we cannot place any trust in the set of potential leaders or assume any built-in Sybil resistance. While this is our motivating application, we consider this type of leader election to be useful in any application in which some limited set of untrusted participants should be eligible to take some action.
4.1 The setting
We consider a round-based leader election protocol run between a set of participants ; that is, a protocol in which the participants want to agree on who is eligible to take some action (e.g., propose a new block) in some future round .
Each participant maintains some private state , and all participants are expected to agree on some public state . For ease of exposition, we assume each includes the public state . We refer to a message sent by a participant as a transaction, denoted , where this transaction can either be broadcast to other participants (as in a more classical consensus protocol) or committed to a public blockchain.
Our model is inspired by the classical approach of coin-tossing protocols that proceed in a commit-then-reveal fashion. It consists of four algorithms and one interactive protocol, which behave as follows:
is used to establish the initial public state .
is used by a participant to commit themselves to participating in the leader election up to some round . This involves establishing both an initial private state and a public announcement .
is run amongst the committed participants, each of whom is given and their own private state , in order to update both the public state and their own private states to prepare the leader election for round .
is used by a participant to broadcast a proof of their eligibility for round (or if they are not eligible).
is used by a participant to verify a claim of eligibility for round .
4.2 Security properties
We would like a leader election protocol to achieve three security properties: liveness, unpredictability, and fairness. The first property map to the established property of liveness for classical consensus protocols, although as we see below we consider several different flavors of unpredictability that are specific to our motivating blockchain-based application. The final one, fairness (also called chain quality ), is especially important in open protocols like blockchains, in which participation must be explicitly incentivized rather than assumed.
We begin by defining liveness, which requires that consensus can be achieved even if some fraction of participants are malicious or inactive.
Definition 4.1 (Liveness).
Let be the fraction of participants controlled by an adversary . Then a leader election protocol satisfies -liveness if it is still possible to elect a leader even in the face of such an ; i.e., if for every public state that has been produced via with the possible participation of , it is still possible for at least one participant, in a round , to output a value such that .
Next, unpredictability requires that participants cannot predict which other participants will be elected leader before some point in time.
Definition 4.2 (Unpredictability).
A leader election protocol satisfies unpredictability if, prior to some step in the protocol, no PT adversary can produce better than a random guess at whether or not a given participant will be eligible for round . If is the step in which a participant broadcasts , and we require to guess only about the eligibility of honest participants (rather than participants they control), then we say it satisfies delayed unpredictability. If it is still difficult for to guess even about their own eligibility, we say it satisfies private unpredictability.
Most consensus protocols satisfy only the regular variant of unpredictability we define, where is the point at which the interaction is “ready” for round (e.g., the participants have completed a coin-tossing or other randomness-generating protocol). This typically occurs at the start of the round, but may also occur several rounds before it.
If an adversary is aware of the eligibility of other participants ahead of time, then it may be able to target these specific participants for a denial-of-service (DoS) attack, which makes achieving liveness more difficult. A protocol that satisfies delayed unpredictability solves this issue, however, as participants reveal their own eligibility only when they choose to do so, by which point it may be too late for the adversary to do anything. (For example, in a proof-of-stake protocol, if participants include proofs of eligibility only in the blocks they propose, then by the time the leader is known the adversary has nothing to gain by targeting them for a DoS attack.)
A protocol that satisfies private unpredictability, in contrast, is able to prevent an adversary from inflating their own role as a leader. For example, if an adversary can predict many rounds into the future what their own eligibility will be, they may attempt to bias the protocol in their favor by grinding  through some problem space in order to produce an initial commitment that yields good future results.
Private unpredictability thus helps to guarantee fairness, which we define as requiring that each committed participant is selected as leader equally often. While for the sake of simplicity our definition considers equal weighting of participants, it can easily be extended to consider participants with respect to some other distribution (e.g., in a proof-of-stake application, participants may be selected as leader in proportion to their represented “stake” in the system).
Definition 4.3 (Fairness).
A leader election protocol is -fair if for all PT adversaries controlling an fraction of participants, the probability that is selected as leader is nearly uniform; i.e., for all , , (where again has been produced by with the possible participation of ), and created by ,
5 Caucus: A Leader Election Protocol
In this section, we present Caucus, a leader election protocol with minimal coordination that satisfies fairness, liveness, and strong notions of unpredictability. In Section 6, we present and evaluate an implementation of Caucus using the Ethereum blockchain.
To begin, we present a straw-man solution in Section 5.1. The benefits of this solution are that it in fact requires no coordination whatsoever; participants are elected leader based on privately held (but publicly committed to) beliefs about their own eligibility, which they then reveal to other participants when relevant. While this means the protocol achieves liveness and the strong notion of delayed unpredictability, it cannot achieve fairness due to participants’ reliance on their own personal randomness, which they can bias without significant effort.
To address this shortcoming, in Section 5.2 we discuss how to fold a source of shared randomness into our protocol in order to make it fair.
Unfortunately, even the best of these solutions still requires significant coordination, which is prohibitively expensive in a setting in which we want leader election to occur frequently (e.g., every time a new block is produced). Thus, in Section 5.3 we explore how to bootstrap the guarantees of these protocols to extend the randomness in a cheaper way. Here our techniques are inspired by the RanDAO protocol described by Buterin .
Finally, we put everything together and present in Section 5.4 our full solution, Caucus, which combines the private randomness of our straw-man solution, in order to achieve delayed unpredictability, with a cheap source of public randomness, in order to achieve fairness and private unpredictability.
5.1 A straw-man solution
We begin with a simple straw-man solution in which participants commit to some privately held randomness by forming a hash chain; i.e., a list such that for some random seed and for all , . We denote by the application of to for times.
In , the public state is just initialized to be an empty list; eventually, it will contain a list of commitments posted by participants, in the form of the heads of their hash chains. For this and all of our subsequent solutions, we assume participants have generated signing keypairs and are aware of the public key associated with each other participant (which can easily be achieved at the time participants run ). We omit the process of generating keys from our formal descriptions but denote by the participant associated with a given transaction (which corresponds to the public key used to sign it).
To to be considered as potential leaders, participants must place a security deposit, that involves creating a commitment to their randomness. In our implementation in Section 6, this entails including the commitment in a transaction that also puts into escrow some monetary value and sending it to an Ethereum smart contract, but in general the commitment could just be a message broadcast to all other participants. This means the function picks a random seed, forms a hash chain of length , and returns the seed itself as the private state of the participant and the head of the hash chain (incorporated into a transaction) as the transaction to add to the public state. More formally:
The eligibility of each participant to act as leader is then based purely on the privately held beliefs contained inside their hash chain. In particular, this solution requires no coordination and thus no protocol. Instead, in each round a participant can check if they are eligible by checking if for (i.e., the maximum hash value divided by the number of potential leaders in ). They can then prove their eligibility by peeling back to that layer of their hash chain, which means running as follows:
As with , in a more general system this could involve simply broadcasting the value itself, rather than forming it into a transaction.
Finally, once a transaction has been broadcast, other participants can verify the eligibility of that participant by checking that the layer revealed correlates with the commitment to their hash chain. More formally:
As stated, participants can join by broadcasting a transaction at any time after the protocol has started. To maintain unpredictability, however, participants should become eligible only after some fixed number of rounds have passed since they ran . In this case, would check not only that , but also that (where is the round in which the participant broadcast and is the required number of interim rounds).
Because of its lack of coordination, and as long as the commitment hides the previous values in the hash chain, this protocol clearly satisfies delayed unpredictability, as participants never talk to each other before they reveal their own eligibility. It also achieves a notion of liveness, as again participants do not rely on each other to establish their own eligibility. It could be the case in some round, however, that no participant is elected leader. In this case, to maintain liveness we consider that if after a small delay no participants have broadcast a transaction, we skip the round and participants update the value of as . This ensure that the protocol keeps running and that a participant will be elected in some future round.
If is a random oracle, then the protocol described above satisfies liveness and delayed unpredictability.
The protocol satisfies liveness, as no coordination is required amongst participants. In particular then, any online participant can communicate their own eligibility to other online participants and be considered leader. The exception is if no online participants satisfy the condition that , but then we can either skip this round as explained above, or modify to ensure that this never happens.
To satisfy delayed unpredictability, we must show that— unless it has formed itself— no adversary can predict whether or not before the point at which it is given , and thus in particular before it is given itself. In the protocol, the adversary sees as part of the commitment of the relevant honest participant, and if that participant has run before it may have also seen for . In the worst case, it has seen this for , meaning it has seen .
If we define , then this is equivalent to giving to and asking it to predict some predicate , where in this case if and otherwise. By the unpredictability of random oracles (Definition 3.1), we know that this is not possible. ∎
If we use as described above, then in theory our protocol should also be able to establish fairness if is uniformly distributed. Indeed, by setting on a per-participant basis, we could even satisfy more complex fairness guarantees, such as ensuring that participants who have put more money into escrow in their security deposit get chosen as leader more often.
As is chosen by each participant rather than uniformly at random, however, we cannot actually guarantee fairness. In particular, participants can grind through different seeds in order to find one that unfairly favors them. This is due partially to the fact that the protocol is not privately unpredictable with respect to any well defined barrier: once the adversary has decided on a seed, it can predict its own eligibility in all future rounds (modulo the shifting number of participants, which it can either grind through as well, or wait until the number of participants is established before grinding).
If is a random oracle, then the protocol described above is not fair.
is a random oracle, every element in the hash chain can be modeled as a random variable uniformly distributed on. For a given seed , the probability for a given that is thus .
Define to be the number of hashes in a hash chain of length where ; i.e., .
is thus a sum of Bernoulli random variables, meaning it follows a Binomial distribution. It it possible for the adversary to grind (i.e., iterate) through different seeds in order to find one that performs better.
In particular, an adversary can break fairness as follows: it tries many different seeds in order to find one for which for some (with ). By the properties of Binomial distribution, we have that
If we define this last term to be , then the expectation on the number of trials needed for the adversary to find such a seed is . In each trial, the adversary computes hashes, so in total it needs to compute hashes. ∎
5.2 Folding in randomness
Given the limitation of our straw-man solution that adversaries can grind through random seeds, and thus fairness does not hold, we must consider ways to improve this guarantee.
We begin by considering other solutions that do not have randomness, or that rely on some source of randomness produced without an explicit coin-tossing protocol. First, as suggested by Buterin , we consider using rather than just using . While this improves matters, as now an adversary controlling several different participants would have to grind through separate seeds for each of them (as opposed to finding one good seed and reusing it across all of them), a grinding attack is still possible so the protocol is not fair.
In any solution where the source of randomness is purely private, it seems somewhat impossible to prevent attacks on fairness, as adversaries can always privately work to bias their own randomness, whether in the form of privately held beliefs about their own eligibility or public randomness that they produce single-handedly. Furthermore, if the source of randomness were known too far in advance (such as if we tried to use something like , which is uniformly random if we model as a random oracle), then the value would be known too far ahead of time to achieve unpredictability, in which— as we see in the proof of Theorem 5.3— participants must commit before knowing the randomness in a given round.
To obtain meaningful notions of fairness and unpredictability, it thus seems necessary to incorporate a source of public, globally sourced randomness. To augment our straw-man solution using such randomness, we first consider an interactive protocol that acts to establish some shared randomness for a given round. This randomness would then be folded into the straw-man solution by requiring not that but that . This results in the following changes:
In order to maintain liveness, we consider that if no participant has revealed before some delay, we update the random beacon as . If is a secure random beacon, then we have the following theorem:
If is a random oracle and was produced by a random beacon satisfying liveness (Definition 3.3), unpredictability (Definition 3.4), and unbiasability (Definition 3.5), then this protocol satisfies liveness, fairness, delayed unpredictability (i.e., where is the step at which the elected leader reveals their proof), and private unpredictability (where is the step at which the randomness is fixed).
For liveness, a participant is elected if they broadcast a valid transaction , such that . If satisifies liveness then an adversary controlling participants cannot prevent honest participants from agreeing on . In the case where no participants produce a value such that , we update the value of as described above until one participant is elected. With a similar argument as in the proof of Lemma 5.1, the protocol thus achieve liveness.
For fairness, a participant wins if . By the assumption that is unpredictable, and thus unknown at the time an adversary commits to , the distribution of the two values is independent. Combining this with the assumption that is unbiasable and thus uniformly distributed, we can argue that is also uniformly distributed. This implies that the probability that the winning condition holds is also uniformly random, as desired.
The argument for delayed unpredictability is almost identical to the one in the proof of Lemma 5.1: even when is known, if has not formed itself then by the unpredictability of the random oracle it cannot predict the value of , where if and otherwise.
Finally, private unpredictability follows from the unpredictability of and from the independence of and . ∎
To be compatible with our implementation in Section 6, the concrete random beacon we use is the SCRAPE protocol, due to Cascudo and David . For completeness, we sketch the original protocol and present our modifications to it in Appendix A. While we chose SCRAPE due to its low computational complexity and compatibility with public ledgers, several other protocols would be suitable as well, such as RandShare or RandHound , or the randomness generation process used in Ouroboros . Indeed, all of these solutions are similar in that they instantiate a publicly verifiable secret sharing (PVSS) scheme (also defined in Appendix A).
5.3 Extending an initial random beacon
While any random beacon protocol provides the necessary security guarantees for Theorem 5.3, all existing protocols are relatively expensive in terms of both local computations and, more crucially, coordination costs. This is not desirable in a setting such as proof-of-stake, in which leader election must be run frequently and continuously.
To minimize these costs, we therefore consider a significantly cheaper solution in which the random value is initialized using a secure coin-tossing protocol, but is then extended and updated using an approach inspired by RanDAO .
In this protocol, participants place security deposits just as they did in our straw-man solution, meaning they run the exact same algorithm, and each commitment is added to the public list .
To initialize the random value, participants now run a coin-tossing protocol to generate a random value (in our implementation in Section 6 we use SCRAPE, but again any secure coin-tossing protocol could work).
For each subsequent round, participants then verify whether or not they are eligible to fold their randomness into the global value by checking if , where . If this value holds, then they reveal their additional randomness by running the same algorithm as in our straw-man solution, which others can verify in the same way as well. If the participant is deemed to in fact be eligible, then the global randomness is updated as . In this setting, however, an adversary that controls participants could get lucky, privately predict that they will be elected leader for a few rounds, and choose their new seed value accordingly. To thwart this, we can again make sure participants have to wait some number of rounds after they committed. This raises the probability that an honest participants will be elected leader between the time an adversary commits and the time they are allowed to participate, thus making the random beacon truly unpredictable and grinding attacks ineffective.
In a general system, each participant would need to maintain their own local copy of and update it appropriately. In a system such as the Ethereum blockchain (where RanDAO was originally proposed for use), a smart contract can act to verify the claims of participants and fold the randomness in by itself. This makes the contract the authoritative source of randomness, and because it is on the blockchain it is also globally visible.
For liveness, the argument is the same as in the proof of Lemma 5.1: after initialization, no coordination is required, so any online participant can communicate their own eligibility to other online participants, allowing them to compute the new random value. In the case where no participant is elected leader after some delay, then we consider that participants update their random value by until a leader is elected.
For fairness, we proceed inductively. By assumption, is initialized in a fair way, which establishes the base case. Now, we assume that is uniformly distributed, and would like to show that will be as well. By the same argument as in the proof of Theorem 5.3, by the unpredictability of and the fact that an adversary commits to before , the value of is independent of the value of and can be considered as a constant.
If we define a value , and denote , then we have
which we know to be uniformly random by assumption, thus for every , we have and for every value , , proving fairness. (Here denotes the bitlength of .)
For unpredictability, we must show that, unless the adversary is itself the next leader, it is hard to learn the value of before it receives . We have , where is assumed to be known. By the same argument about the unpredictability of as in Lemma 5.1, however, if it belongs to an honest participant and is modeled as a random oracle, then the adversary is unable to predict this value and thus unable to predict . ∎
Even if the initial value was some constant (e.g., 0) instead of a randomly generated string, we could still argue that the protocol is fair after the point that the randomness of at least one honest participant is incorporated into the beacon. Indeed in this case the value of the beacon would be updated as where is random since it belongs to an honest participant, and independent of , since it was committed to before round , so this new value is random. This assumption is weakened the longer the beacon is live, so works especially well in settings such as we describe in Section 7.2, in which the leader election protocol is used to bootstrap from one form of consensus (e.g., PoW) to another (e.g., PoS).
5.4 Our construction: Caucus
Now that we have a cheap source of continuous randomness, we combine it with the privately held beliefs in our straw-man solution in Section 5.1 to give our full solution, Caucus. The protocol is summarized in Figure 1.
If is a random oracle and is initialized as a uniformly random value, then Caucus is a secure leader election protocol; i.e., it satisfies liveness, fairness, delayed unpredictability (i.e., where is the step at which the elected leader reveals their proof), and private unpredictability (where is the step at which the randomness is fixed).
This theorem holds by the security of the components of the system, and in particular because the security of the random beacon (Theorem 5.4) implies that the necessary conditions for the security of the randomized solution (Theorem 5.3) hold. We thus get all of the same properties as the solution proven secure in that theorem. In terms of the fraction of malicious participants that we can tolerate, it is , where is the threshold of the PVSS scheme used to initialize the random beacon (see Appendix A for more details). After the random beacon is initialized, if implemented in Ethereum our protocol then requires no further coordination, so can tolerate any fraction. In the context of proof-of-stake, however, we would still need to assume an honest majority. ∎
Finally, in addition to the possibility that no participant “wins” a given round, it is also possible that there will be two or more winners in a round. In a pure leader election protocol, we could simply elect all winning participants as leaders. In a setting such as proof-of-stake, however, being elected leader comes with a financial reward, and conflicts may arise if two winners are elected (such as the nothing-at-stake problem discussed in Section 3.4.1). While we leave a full exploration of this as future work (as again this issue does not arise in the abstract context of leader election), one potential solution (also suggested by Algorand ) for electing a single leader is to require all participants to submit their winning pre-image before some time , and then select as the winner the participant whose pre-image has the lowest bit value.
6 Implementation and Performance
In this section, we present the implementation of Caucus as a suite of Ethereum smart contracts, our experience running the protocol on a private Ethereum test network,111Our full smart contract cannot be deployed on the test network as blocks support only up to 4.7 million gas, whereas the production network supports 6.7 million gas. and the technical difficulties we faced. The main reason for doing so is to get an idea of the cost of such a protocol.
6.1 Implementation details
We implemented the Caucus protocol as three smart contracts written in the Solidity language; together, they are approximately 950-1,000 lines of code.222 https://www.dropbox.com/s/n89xq4ta17a4n0p/Dealer.sol333https://www.dropbox.com/s/yde7e5ja55wq1sb/Dealer_voting.sol The first two contracts, Dealer and Scrape, implement the SCRAPE random beacon of Cascudo and David  (which we describe in more depth in Appendix A), and Caucus implements our full leader election protocol. Furthermore, there is an optional LocalCrypto444https://www.dropbox.com/s/ajzgdw7v59ms43k/LocalCrypto.sol contract adopted from  that contains the code for creating the zero knowledge proofs.
To set up Caucus, a single party creates the Caucus contract (Step 1) that establishes deadlines the maximum round time , and the required registration deposit . Next, Caucus creates the Scrape contract (Step 2) before beginning the registration phase. Participants run (Step 3) to deposit coins, and also indicate whether or not they want to participate in SCRAPE. Finally, registration is closed after and Scrape creates a new Dealer contract (Step 4) for each participant that indicated interest. All dealers are set as participants in other dealer contracts (Step 5) before Scrape transitions to the commit phase and all Dealer contracts transition to the distribution phase (Step 6).
To now initialize the random beacon using SCRAPE, each dealer runs the secret sharing phase of SCRAPE and publishes the resulting encrypted shares and discrete log equality proofs (DLEQ) to the contract, which it then processes (Step 7). In our fully on-chain variant of Caucus, the Dealer contract also runs all necessary verifications before storing both the committed and encrypted shares (Step 8a).
Because this type of on-chain verification is financially expensive (as it requires the contract to execute complex operations with high gas costs), we also consider a voting-based variant that adopts the techniques of RandShare  to reduce on-chain costs but preserve liveness. In this variant, the contract stores the shares and proofs but doesn’t perform any verification itself. Instead, participants perform the verification themselves off-chain, and then cast a vote to indicate their support accordingly (Step 8b). The contract accepts encrypted and committed share once more than participants have voted that the proof is correct.
The Scrape contract transitions to the recovery phase after , and is responsible for transitioning all dealer contracts that completed the distribution phase to the recovery phase (Step 9). Caucus forfeits the deposit of any dealers that failed to finish the distribution phase. In this next phase, more than participants must publish their decrypted share and a DLEQ that it corresponds to the encrypted version in the respective Dealer contract. In our on-chain variant, the Dealer contract verifies the DLEQ before storing the decrypted share (Step 10a). In our voting variant, the contract stores it regardless and then waits for an appropriate number of positive votes about its validity (Step 10b). Once a sufficient number of shares (and votes, if applicable) are available, the contract combines the shares to compute the dealer’s secret (Step 11). The Scrape contract then combines all dealer secrets to compute the final beacon and transitions Caucus to the election phase (Step 12). Caucus forfeits the deposits of any participants that did not publish their decrypted share before .
At each round during the election phase, participants can run to send a value to the contract. The contract runs to check that the participant has indeed won the election before computing the next beacon value and starting the next round (Step 13). If there is no winner after , then the next value is computed as .
6.2 Gas costs for cryptographic operations
All cryptographic operations are implemented over the
in Solidity. The creation code for the DLEQ proofs needed for SCRAPE is
distributed using the optional LocalCrypto contract and the DLEQ
verification code is distributed in the Dealer contract.
We briefly explore the number of multiplications and additions required for
verifying the correct execution of the protocol (on-chain verification) before
highlighting the gas that can be saved using the voting approach (off-chain
We focus on the gas costs for on-chain verification in both the distribution and recovery phases (Steps 8a and 10b respectively), in which participants send the contract DLEQ proofs. Each DLEQ proof involves 4 MUL and 2 ADD operations which is approximately 1.5-1.4M (million) gas. Validating the committed shares published by the Dealer in Step 8a requires MUL and ADD operations which is approximately 2.1M gas when and the gas cost increases linearly for each additional committed share. Finally, combining all decrypted shares in Step 11 involves MUL and ADD operations which is approximately 550k gas when .
We focus on the gas costs for participants casting votes on whether the proofs are correct in both the distribution and recovery phases (Steps 7 and 9 respectively). This requires transactions, since is the number of Dealer contracts and is the number of participants in each contract. A single vote to confirm that all encrypted and committed shares distributed by the dealer are well formed requires approximately 42k gas. On the other hand, a participant (and the respective dealer) must vote on whether or not decrypted shares distributed by other participants are well formed. A single vote on all 6 decrypted shares requires approximately 400k gas. Although the voting approach involves an additional 76 transactions overall, it also requires 104M less gas.
6.3 Financial costs
|Step||Purpose||On-chain protocol||Voting protocol|
|Cost (gas)||Cost ($)||# txns||Cost (gas)||Cost ($)||# txns|
|3||Register a participant|
|5||Set participants in all Dealer|
|6||Transition Dealer to distribution stage|
|7||Process encrypted shares in Dealer|
|8a||Validate committed shares for a dealer||—||—||—|
|8b||Process votes on encrypted shares||—||—||—|
|9||Transition Scrape to recovery stage|
|10a||Process decrypted shares in Dealer|
|10b||Process votes on decrypted shares||—||—||—|
|11||Join all decrypted shares in a dealer’s contract|
|12||Transition Caucus to election stage|
|13||Elect a leader (per round)|
|Create all contracts|
|Elect a leader (per round)|
presents the estimated financial costs for setting up and running Caucus on the Ethereum network, both in terms of the gas costs associated with each individual step described in Section6.1, as well as the aggregate costs for each phase of the protocol. The conversions used were taken as their real-world values in December 2017 (ethgasstation.info).
The total cost for creating all contracts is $54.8 in the on-chain variant and $52.1 in the voting-based variant. This cost is incurred only once, as the contract can be stored once in the blockchain and DELEGATECALL can re-use this code to create a new instance of each contract.
The total cost for executing the SCRAPE protocol is $271 in the on-chain variant and $79.8 in the voting-based variant. After this initial round, the total cost for running a single round of Caucus is then $0.10, if the contract must perform only a single hash to verify against the committed head of the hash chain; i.e., if . The cost for each additional hash is 128 gas, which is roughly $0.0001.
Overall, the initial cost to deploy Caucus’s initial contracts is around $50. If a secure random beacon is required from the very start, then the cost can be kept under $80 using the voting-based approach. On the other hand, if a secure random beacon is not required immediately (i.e. the beacon is used to bootstrap a proof of stake protocol as we describe in Section 7.2), then it is possible to avoid SCRAPE altogether. However, relying solely on Caucus assumes that at least one honest participant has contributed to the beacon before bootstrapping begins. Either way, the cost to continue the random beacon and thus elect new leaders is only $0.10.
7 Improvements and Extensions
In this section we discuss how the basic Caucus protocol presented in Section 5 can be changed to detect misbehaving participants, and how it can be integrated with existing blockchains based on proof-of-work (PoW) to enable proof-of-stake (PoS).
7.1 Detecting bias
In our current protocol specification, the winner of a leader election could potentially bias the beacon by simply not revealing the value . If the contract were updated to store a list of the recent values produced by the random beacon and participants were required to periodically reveal a list of pre-images, then the protocol could retroactively detect this behavior. In particular, it could check for each beacon value and for all participants with value at the appropriate round whether or not , and also whether or not the participant submitted . If the inequality holds but the value was not submitted, then the contract can punish the participant appropriately by, for example, taking their security deposit.
7.2 Bootstrapping PoS from PoW
The Ethereum Foundation plan to switch Ethereum’s consensus protocol from proof of work to proof of stake , which motivates the need for a protocol that can facilitate this transition. Our implementation demonstrates that Caucus can be set up as a smart contract to satisfy this transition at a reasonable cost, and because it facilitates an open-membership policy that allows anyone to register and participate in leader elections. A proof-of-stake protocol could then take over as the new consensus protocol after numerous leader elections in Caucus, which would also increase the possibility that a single honest participant had contributed to the random beacon (and thus meaning we could avoid the expensive step of initializing it using a coin-tossing protocol).
The missing part of Caucus in order to present a full PoS protocol is a reward and punishment scheme that solves the nothing-at-stake and long-range attacks described in Section 3.4.1. We have intentionally left this problem for future work to instead focus on rigorously analyzing our leader election protocol.
8 Conclusion and Open Problems
In this paper, we presented Caucus, a leader election protocol that, among other potential applications, could be used to bootstrap a PoW-based blockchain to a PoS-based one. To analyze Caucus, we presented cryptographic notions of security specific to the setting of blockchains; namely, unpredictability, fairness and liveness. We then proved that Caucus satisfies strong variants of these security properties, while requiring only minimal coordination between the participants. While other papers try to solve the proof-of-stake problem all at once, we instead focused on the security properties of the leader election, which is a well studied problem in the distributed system literature but one that needs a different formalization in the context of blockchains. More generally, it is difficult to compare the different PoS protocols that have been proposed, and we believe our model makes steps towards providing a formal model that allows for meaningful comparisons.
Due to our focus on leader election, we leave as a future work an economic incentivization scheme that would be needed to provide a full solution to the PoS problem, as proof-of-stake problem consists mostly of a secure leader election combined with an incentive-compatible reward and punishment scheme.
-  https://bitcointalk.org/index.php?topic=27787.0, 2011.
-  https://bitcointalk.org/index.php?topic=458726.0, 2014.
-  N. Alon and M. Naor. Coin-flipping games immune against linear-sized coalitions. SIAM J. Comput., 22(2):403–417, Apr. 1993.
-  M. Ben-Or and N. Linial. Collective coin flipping. http://www.cs.huji.ac.il/~nati/PAPERS/coll_coin_fl.pdf.
-  M. Ben-Or and N. Linial. Collective coin flipping, robust voting schemes and minima of banzhaf values. In 26th FOCS, pages 408–416, Portland, Oregon, Oct. 21–23, 1985. IEEE Computer Society Press.
-  I. Bentov, R. Pass, and E. Shi. Snow white: Provably secure proofs of stake. IACR Cryptology ePrint Archive, Report 2016/919, 2016. https://eprint.iacr.org/2016/919.
-  M. Blum. Coin flipping by telephone a protocol for solving impossible problems. SIGACT News, 15(1):23–27, Jan. 1983.
-  J. Bonneau, J. Clark, and S. Goldfeder. On bitcoin as a public randomness source. Cryptology ePrint Archive, Report 2015/1015, 2015. http://eprint.iacr.org/2015/1015.
-  V. Buterin. Validator ordering and randomness in PoS. vitalik.ca/files/randomness.html.
-  R. Canetti. Towards realizing random oracles: Hash functions that hide all partial information. In B. S. Kaliski Jr., editor, CRYPTO’97, volume 1294 of LNCS, pages 455–469, Santa Barbara, CA, USA, Aug. 17–21, 1997. Springer, Heidelberg, Germany.
-  I. Cascudo and B. David. Scrape: Scalable randomness attested by public entities. Cryptology ePrint Archive, Report 2017/216, 2017. http://eprint.iacr.org/2017/216.
-  A. Chepurnoy. Interactive proof-of-stake. CoRR, abs/1601.00275, 2016.
-  B. Chor, S. Goldwasser, S. Micali, and B. Awerbuch. Verifiable secret sharing and achieving simultaneity in the presence of faults (extended abstract). In 26th FOCS, pages 383–395, Portland, Oregon, Oct. 21–23, 1985. IEEE Computer Society Press.
-  G. Danezis and S. Meiklejohn. Centrally banked cryptocurrencies. In NDSS 2016, San Diego, CA, USA, 2016. The Internet Society.
-  B. David, P. Gaži, A. Kiayias, and A. Russell. Ouroboros praos: An adaptively-secure, semi-synchronous proof-of-stake protocol. Cryptology ePrint Archive, Report 2017/573, 2017. http://eprint.iacr.org/2017/573.
-  U. Feige. Noncryptographic selection protocols. In Proceedings of the 40th Annual Symposium on Foundations of Computer Science, FOCS ’99, pages 142–, Washington, DC, USA, 1999. IEEE Computer Society.
-  Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich. Algorand: Scaling byzantine agreements for cryptocurrencies. Cryptology ePrint Archive, Report 2017/454, 2017. http://eprint.iacr.org/2017/454.
-  O. Goldreich. Foundations of Cryptography: Basic Applications, volume 2. Cambridge University Press, Cambridge, UK, 2004.
-  A. Kiayias, A. Russell, B. David, and R. Oliynykov. Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol, pages 357–388. Springer International Publishing, Cham, 2017.
-  S. King and S. Nadal. PPCoin: Peer-to-peer crypto-currency with proof-of-stake, 2012. https://peercoin.net/assets/paper/peercoin-paper.pdf.
-  V. King, J. Saia, V. Sanwalani, and E. Vee. Scalable leader election. In Proceedings of the Seventeenth Annual ACM-SIAM Symposium on Discrete Algorithm, SODA ’06, pages 990–999, Philadelphia, PA, USA, 2006. Society for Industrial and Applied Mathematics.
-  L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena. A secure sharding protocol for open blockchains. In ACM CCS 16, pages 17–30. ACM Press, 2016.
-  P. McCorry, S. F. Shahandashti, and F. Hao. A smart contract for boardroom voting with maximum voter privacy. Financial Cryptography and Data Security, 2017.
-  A. Miller, Y. Xia, K. Croman, E. Shi, and D. Song. The honey badger of BFT protocols. In ACM CCS 16, pages 31–42. ACM Press, 2016.
-  S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system,” http://bitcoin.org/bitcoin.pdf.
R. Ostrovsky, S. Rajagopalan, and U. Vazirani.
Simple and efficient leader election in the full information model.
Proceedings of the Twenty-sixth Annual ACM Symposium on Theory of Computing, STOC ’94, pages 234–242, New York, NY, USA, 1994. ACM.
-  R. Palmieri. Leaderless consensus: The state of the art. In 2016 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW), pages 1307–1310, May 2016.
-  S. Popov. On a decentralized trustless pseudo-random number generation algorithm. Cryptology ePrint Archive, Report 2016/228, 2016. http://eprint.iacr.org/2016/228.
-  M. Rabin. Transaction protection by beacons. Technical Report 29-81, Aiken Computation Laboratory, Harvard University, 1981.
-  A. Russell and D. Zuckerman. Perfect information leader election in log*n+o(1) rounds. J. Comput. Syst. Sci., 63(4):612–626, Dec. 2001.
-  M. Saks. A robust noncrytographic protocol for collective coin flipping. SIAM J. Discret. Math., 2(2):240–244, May 1989.
-  B. Schoenmakers. A simple publicly verifiable secret sharing scheme and its application to electronic. In M. J. Wiener, editor, CRYPTO’99, volume 1666 of LNCS, pages 148–164, Santa Barbara, CA, USA, Aug. 15–19, 1999. Springer, Heidelberg, Germany.
-  A. Shamir. How to share a secret. Communications of the Association for Computing Machinery, 22(11):612–613, Nov. 1979.
-  E. Syta, P. Jovanovic, E. K. Kogias, N. Gailly, L. Gasser, I. Khoffi, M. J. Fischer, and B. Ford. Scalable bias-resistantdistributed randomness. Cryptology ePrint Archive, Report 2016/1067, 2016. http://eprint.iacr.org/2016/1067.
-  V. Zamfir. Introducing Casper “the friendly ghost”, Aug. 2015. blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/.
Appendix A Scrape
The SCRAPE protocol  instantiates a publicly verifiable secret sharing (PVSS) scheme in order to achieve a publicly verifiable random beacon. As discussed in Section 5, we have decided to incorporate SCRAPE into Caucus due to its low computational complexity and its compatibility with public ledgers.
Briefly, a -threshold secret sharing scheme  consists of a set of participants and a dealer who distributes shares of a secret among the participants in such a way that or more of them can recover the secret . A publicly verifiable secret sharing (PVSS) scheme [13, 32] has the additional property that anyone can verify that the shares have been computed correctly and allow the participants to recover a valid secret. This means that PVSS schemes consist of a distribution phase (in which encrypted shares are distributed and their correctness can be publicly verified) and a recovery phase (in which encrypted shares are decrypted and revealed, and can be recovered in the event that some of the initial participants have gone offline).
a.1 The original SCRAPE protocol
Briefly, the original SCRAPE protocol proceeds as follows: the parameters consist of generators and of a group of prime order , as well as a hash function modeled as a random oracle. is also defined to be the linear error correcting code corresponding to the -threshold Shamir secret sharing scheme, and let be its dual code.
To register, each participant generates a secret key and a public key , and publishes to the ledger.
In the distribution phase, the dealer picks a secret and computes the shares of the secret, where is the number of registered participants. Then, each dealer publishes a list of encrypted shares , where , a list of committed shares , where , and a list of discrete log equality proofs that each pair of encrypted and committed shares correspond to the same discrete log. To verify these values, anyone can verify the list of DLEQ proofs before sampling random codewords of the dual code , corresponding to the instance of Shamir’s -threshold secret sharing used by , and verify that .
In the recovery phase, each participant decrypts their share as and publishes a new proof that the decrypted share corresponds to the encrypted share. These proofs can again be verified by anyone. Finally, the dealer’s secret
can be recovered once half the shares are decrypted using Lagrange interpolation (whereare the Lagrange coefficients); i.e., by computing
More details and a proof of security (assuming DDH and modeling as a random oracle) can be found in the original SCRAPE paper .
a.2 Our modified protocol
To make the abstract SCRAPE protocol compatible with our Ethereum-based implementation required several modifications that we highlight here.
First, as discussed in Section 6.1, we included an additional timer that allows the contract to dictate the end of the distribution phase, whereas in the original SCRAPE protocol the recovery phase is said to start after dealers have finished the distribution stage. This was done in order to provide a grace period for all dealers to publish their commitment before transitioning to the recovery stage. We still require that .
Second, the original SCRAPE protocol proposes as an optimization that the dealer could send an additional commitment to the full secret in the distribution phase, and then open it in the recovery phase; this would mean the other participants wouldn’t have to recover it. There is no proposed method in the paper, however, for the dealer to prove that this additional commitment is the same secret that would ultimately be derived from the decrypted shares. Without such a proof, the dealer could commit to a second secret and then choose to either allow the participants to recover or to reveal ; this would in turn allow it to bias the beacon. To avoid this type of behavior, we chose not to include this optimization.
Third, the original SCRAPE protocol suggests picking a random codeword in order to perform verification. In our fully on-chain variant, verification is performed by the contract, which has no source of randomness on which to draw. Instead then, it uses as a random seed the hash of the most recent block to do this sampling.
Finally, all DLEQ proofs in SCRAPE rely on a single challenge , which is the hash of all commitments, ciphertexts, and other random factors. It is not feasible to include all this information in a single transaction as a Solidity function can only support 16 local variables (including its parameters). Instead, the dealer sends one proof per transaction, along with the value that the dealer has computed locally. The contract can verify the proof using the dealer’s supplied before storing the committed and encrypted share. This is necessary to allow the contract to perform both the verification and storage in a single transaction. After verifying all proofs, the contract can re-compute using the stored committed/encrypted shares before proceeding to the reveal phase if . Otherwise, it halts in a failed state.