ProPoS: A Probabilistic Proof-of-Stake Protocol

06/02/2020 ∙ by Daniel Reijsbergen, et al. ∙ 0

We present ProPoS, a Proof-of-Stake protocol dedicated, but not limited, to cryptocurrencies. ProPoS is a chain-based protocol that minimizes interactions between nodes through lightweight committee voting, resulting in a more simple, robust, and scalable proposal than competing systems. It also mitigates other drawbacks of previous systems, such as high reward variance and long confirmation times. ProPoS can support large node numbers by design, and provides probabilistic safety guarantees whereby a client makes commit decisions by calculating the probability that a transaction is reverted based on its blockchain view. We present a thorough analysis of ProPoS and report on its implementation and evaluation. Furthermore, our new technique of proving safety can be applied more broadly to other Proof-of-Stake protocols.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

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

I Introduction

One of the main innovations of Bitcoin [35] is Nakamoto Consensus (NC), a protocol for maintaining a distributed data structure called a blockchain. In NC, each participating node tries to become the round leader by solving a Proof of Work (PoW) puzzle. If a solution is found, the node announces a block that contains a hash link to the previous block, the solution of the PoW puzzle, transactions, and metadata. Potential network forks are resolved by following the longest-chain rule. In this non-interactive leader election process, a block produced in a round acts as the medium of transactions, the leader election proof (easily verifiable by other nodes), and as confirmation of all previous blocks. Hence, confidence in a given chain is built gradually through the addition of new blocks. The protocol can scale to a number of nodes that is vastly too large to be handled by traditional Byzantine Fault Tolerant (BFT) consensus protocols [14], which in every round require significant communication complexity among all nodes. However, NC has some critical limitations, such as its enormous energy footprint, its low throughput, and a slow and insecure finalization process – furthermore, its reward frequency and structure encourage centralization, which in turn amplifies its security vulnerabilities [7, 15, 25].

A promising direction in the mitigation of (some of) these drawbacks involves Proof-of-Stake (PoS) protocols, in which nodes do not vote via their computing power, but with their stake

, i.e., blockchain tokens. A new node needs to obtain stake from the existing nodes; however, for the price of such a semi-permissionless setting, these systems promise multiple benefits. These benefits include reduced energy consumption, as voting is usually based on a cryptographic lottery that relies on short messages instead of resource-intensive PoW puzzles. Furthermore, the transaction throughput can be improved by sequential processing and block propagation at the network rate. Interestingly, as participating nodes and their stake are known upfront, these systems promise to commit blocks faster and with better safety properties, similar to the properties of standard BFT protocols. However, there are many obstacles in the design of new PoS schemes. Several recent systems try to apply the longest-chain rule in the PoS setting. Unfortunately, those proposals mimic Nakamoto’s design decisions that introduce undesired effects such as a high reward variance which leads to centralization 

[22]. Moreover, although they are conceptually similar to NC, whose properties have been investigated in the literature, it has proven challenging to replace PoW-based voting by cryptographic primitives while avoiding fundamental limitations [10]. For instance, unlike NC, where it is expensive to work on solving PoW puzzles on two branches simultaneously (as the node will eventually lose its investment on one branch), it is easy in PoS systems to vote on multiple conflicting branches. This is informally known as the nothing-at-stake problem. Similarly, it is easier to launch long-range attacks in the PoS setting, in which an adversary obtains keys of nodes who controlled a majority of stake in the distant past and creates a long alternative chain.

In this work, we present ProPoS, a PoS protocol that addresses the above limitations while remaining conceptually simple and free from BFT-like message complexity. In our protocol, committee members are randomly and periodically sampled to vote for their preferred main chain views. Evidence for these votes is included in the blocks, and they users to make their own decisions about whether to commit/finalize a block, and therefore act on the transaction in the block (e.g., dispatching package based on a cryptocurrency transaction). In particular, clients calculate the probability that the block can be reverted given how many votes support the block and its descendants, and commit the block if this probability is low enough. By reducing the degree of interaction between committee members, ProPoS can scale to large numbers of active participants. This is combined with a high frequency of blocks and rewards for participating nodes, which mitigates the tendency towards centralization of NC. ProPoS introduces a chain selection algorithm that aims to gather as much information as possible about the nodes’ views, which leads to higher security and faster commit decisions. The CAP theorem [9] restricts distributed systems to select either availability or consistency in the face of network partitions. ProPoS favors availability over consistency; however, in ProPoS partitioned clients would notice that their view of the blockchain does not provide strong safety guarantees for their commit decisions (we propose a novel use of hypothesis testing to analyze it). ProPoS is presented with a fair and coalition-safe rewarding scheme, sadly omitted by many competing systems. We emphasize the impact of the major design choices in ProPoS through a detailed comparison to Algorand [26], which is a closely related PoS protocol. Whereas Algorand’s BFT-like block commitment scheme focuses on individual rounds, ProPoS aggregates information from multiple rounds and hence achieves higher security and flexibility in the sense that each user is able to set her own security thresholds. We thoroughly analyze our system, present the efficiency and deployability of ProPoS through an implementation, and discuss alternative design choices and extensions.

Ii System Model

Participants and Network. Our system comsists of multiple peer nodes who want to achieve consensus over the state of a distributed ledger. The nodes are mutually untrusting with exactly the same rights and functions (i.e., no node or any subset is trusted). Nodes are identified by their unique public keys, and to avoid Sybil attacks [18] we assume that nodes require stake in terms of the underlying cryptocurrency to participate. The initial set of nodes and their stake allocation is pre-defined in a genesis block that is known to all nodes (i.e., the system is bootstrapped from the genesis block). The stake distribution is represented by a mapping between public keys and their corresponding stake units. The system is used by clients who wish to make cryptocurrency transactions and who do not necessarily participate in the consensus protocol (although some may).

We assume that participating nodes have loosely synchronized clocks, as the protocol makes progress in timed rounds. Nodes are connected via a peer-to-peer network in which messages are delivered within seconds during periods of network synchrony. We assume a partially synchronous communication model [19], where the network can be asynchronous with random network delays, but synchrony is eventually resumed after an unknown time period called global stabilization time (GST). We assume that during asynchronous periods, an adversary cannot adaptively control network splits and delays, although the adversary can be omnipresent in all existing splits. We emphasize that similar or stronger assumptions are common among competing systems.

Desired Properties. First, we desire the two following fundamental properties. Liveness: a valid transaction sent to the network is eventually added to the global ledger and committed by all clients. Probabilistic Safety: if for a client-specified probability , the client commits a transaction, then the probability that this transaction is ever reverted is at most . One important aspect of ProPoS is that, unlike in traditional BFT protocols, our definition of safety is probabilistic. The relaxed safety property allows us to scale the system to thousands of active participants and to propose a simple, robust, and high-throughput system, while still achieving strong client- or even transaction-specific safety.

Besides these properties, we present our work in an open cryptocurrency setting – therefore, we aim to achieve the following additional properties. Scalability: the system should scale to a large number of nodes. High Throughput: the system should provide high throughput for transactions, and in particular, the consensus mechanism should not be a bottleneck for this throughput. Efficiency: overheads introduced by the system should be reasonable, allowing system deployment on the Internet as it is today, without requiring powerful equipment or resources (like CPU, memory, and bandwidth). Fairness: an honest node with a fraction of the total stake, should have a presence of approximately in the main chain of the blockchain. This is especially important when the presence in the blockchain is translated into system rewards. Coalition Safety: any coalition of nodes with the total stake , where is a coalition node’s stake, cannot obtain more than a multiplicative factor of the total system rewards for some small .

Cryptography. We make standard cryptographic assumptions and we use the following cryptographic constructions. is a collision-resistant cryptographic hash function, producing a hash value for a message ; is a keyed pseudorandom function (PRF), outputting a pseudorandom string for key and message pair; is a signature scheme that for a secret key and a message produces the corresponding signature ; is a signature verification procedure that returns if is the correct signature of under the secret key corresponding to the public key , and otherwise.

Adversary. We assume an adversary who is able to control nodes possessing “malicious” stake units, for any and where denotes the total number of stake units; hence, honest nodes possess stake units. Adversarial nodes can be byzantine, i.e., they can fail or equivocate messages at the adversary’s will. (We emphasize that is a bound in both our adversary and network models [19].) We assume that the adversary’s goal is to violate the liveness and/or probabilistic safety properties, by a) stopping the progress of the protocol, or b) by causing a non-compromised client to commit a transaction that can be reverted with a probability that is higher than specified by the client. We also discuss adversarial strategies that aim to undermine other protocol properties (such as efficiency, throughput, and fairness).

Iii Protocol

Iii-a Preliminaries

For each node we have a secret/public key pair as well as the amount of associated stake. For simplicity, we assume that the nodes’ stakes are natural numbers that sum to the total stake . ProPoS operates through a blockchain, such that each block contains a set of transactions, a link to the previous block, and various metadata. The structure of a block is


where is the round number (consecutive, starting from 0); is a random value generated by the leader; is the hash of the previous valid block, blocks thus encode the parent-child relationship; is a set of votes that support the previous block (see Eq. 2); is a set of known, to the leader, forked blocks that have not been reported in any previous known block; is a set of transactions included in the block; is the leader’s public key; is a signature, created by the block leader over all previous fields except .

Every block supports its previous block by encoding votes of (elected in the round) nodes who vouched for the previous block as their preferred (main) chain of the blockchain. A vote has the following structure:


where is the round number; is the hash of the previous valid block; is the stake that the vote creator was elected with as a voter for the round ; is the voter’s public key; is a signature, created by the voter over all previous fields except . Essentially, a vote encodes a stake unit with which the voter supports her blockchain view in a given round.

As our blockchain contains blocks that follow a parent-child relation and as it may contain forks, in essence, the final rendered data structure is a directed acyclic graph (DAG) or a tree (see an example in Fig. 2). However, within this DAG only one chain is considered as the main chain whose transactions are strictly ordered. Transactions are initiated by blockchain clients who wish to transfer their crypto tokens or execute a higher-level logic (like smart contracts). We assume that transactions are accompanied by fees paid for appending them to the blockchain. We do not introduce any transaction model or a validation logic for transactions, although models used in other systems can easily be implemented with ProPoS.

Iii-B Voting Round

The protocol bootstraps from the genesis block and makes progress in two-step rounds. The voting procedure of every round is presented in Alg. 1. Each round lasts for seconds and has two steps ( for each step). At the beginning of every round , each node obtains a round’s pseudorandom beacon used to elect the voters and a leader. In § III-F we show concrete instantiations of beacon generation and discuss alternative ways of realizing it.

In the first step of the round, a node checks whether she can vote in this round by calling which returns the number of stake units that the node can use to vote in the round. If a positive number is returned, then the node in that round is called a voter and can vote for (i.e., support) the last block of the main chain (from the node’s perspective). To do so, the voter creates a vote (see Eq. 2) and broadcasts the vote immediately to the network to signal what chain the node supports. Other nodes validate all received votes by checking whether a) it is authentic, formatted correctly, and not from the future (i.e., not with a future round number), b) it points to some previous block (note that in ProPoS forks are allowed), c) the voter is legitimate (i.e., returns the positive stake amount as declared). After a successful verification, a vote is added to the pending list of votes directly supporting the last block. These votes create a so-called virtual block which contains votes that have been collected but not yet included, and one virtual block can support another virtual block (we discuss this further in § III-D).

After waiting for seconds111For a simple description, we avoid message generation and processing time and rely on the parameter for expressing all delays., collecting and validating broadcast votes, the second step of the round starts. Analogously, the node checks the output of the function, and if it is positive then the node is a leader of that round. The node determines the main chain again. Importantly, received votes can change the main chain selected in the previous step – see the details in § III-D. Next, the node creates and propagates a new block including, among other fields – see Eq. 1 – all collected votes and the generated random value . A node receiving a new block verifies if a) it is authentic, formatted correctly, and not from the future, b) it points to some existing block, c) the votes are correct, and d) the leader is legitimate (i.e., returns a positive value). If the block is validated, it is appended to its corresponding chain. Besides pointing to the previous block, a leader in its block lists all known forks that were not reported in previous blocks (including pending votes of other blocks).

1 function VotingRound(i)
2        ; ;
3        if  then // check if I’m a voter
4               ; // get last block
5               ;
6               ; // support vote
7               Broadcast();
9       Wait(); // meanwhile, collect and verify support votes
10        if  then // check if I am a leader
11               ; // possibly different block
12               ; // received ’s support votes
13               ; ;
14               ; // new block
15               Broadcast();
17       Wait(); // wait for the next round
Alg. 1 The voting procedure.

For now we abstract from the actual implementation of leader and voter election, and propose a concrete instantiation in § III-C. However, one requirement of these procedures is that nodes will act as leaders and voters in proportion to their stake possession. Technically, the only reason to have a leader election is to propose blocks and make progress in the protocol. We do not restrict the roles of a node per round, i.e., a node can both be a voter and leader in a given round, or act in only one of these roles, or none.

Iii-C Leaders and Voters Election

We propose a method of electing leaders and voters which is based on cryptographic sampling presented in Alg. 2. The core of this method is to create an array of all stake units and pseudorandomly sample a fraction from it. The method uses uniquely generated PRF outputs to sample stake units.222The construction can be optimized using consecutive bits of every PRF output, as usually, PRF outputs bits where . In a round, leader and voter elections should be independent, thus the function takes a role parameter (‘lead’ and ‘vote’, respectively) to randomize PRF outputs for these two elections. The function returns a list of sampled public keys (each key corresponds to a stake unit) and is parametrized by the parameter determining the size of the list. denotes how many stake units out of the total stake are elected every round for the voting committee, and is an analogous parameter for leaders. The and functions run and return how many times the given public key is present in the sampled stake. In App. A, we show that our construction is indistinguishable from random sampling for computationally bounded adversaries. As stake units are sampled uniformly at random, a node with stake can be elected as a voter between 0 and times in any given round. For performance reasons it may be desirable for one leader to be elected every round, which is achieved by setting .

1 function VoterStake(pk, r)
2        ; return ;
4function LeaderStake(pk, r)
5        ; return ;
7function Sample(size, r, role)
8        ; ;
9        for  do
10               for  do
11                      ;
14       for  do
15               ;
16               ; ;
18       return ;
Alg. 2 Leader/voter election via cryptographic sampling.

This approach guarantees that in every round the exact same stake fraction is sampled. As a result, clients are able to more quickly make commit decisions. However, a disadvantage is that an adversary may try to launch an adaptive attack (e.g., (D)DoS) as elected nodes are known before they broadcast their messages. We discuss ways of mitigating such attacks in App. E-B; however, other election approaches that eliminate this threat can easily be adopted in ProPoS. One way of addressing this issue in PoS blockchains is to use cryptographic primitives with secret inputs (e.g., VRF or unique signatures). When such an approach is applied, a node’s role can be revealed only by this node itself, e.g., by propagating a message. The disadvantage, as we show in § VI-B and App. E-E, is the variance in the number of elected entities (i.e., the number of leaders and voters in every round is only on average equal to and , respectively). In App. E-E, we show how ProPoS can be combined with VRF-based election and how our analysis results are applicable for this case. An efficient mechanism that combines “secret” election with guaranteed committee sizes is an open research problem.

Iii-D Chain Selection

Our chain selection procedure is inspired by two PoW systems. For expressing the strength of blocks and we use a similar approach as in recently-proposed StrongChain [42], where blocks contain multiple (relaxed) PoW solutions to express the network’s combined PoW. To improve the handling of forks, we use the GHOST protocol [40], proposed to improve the throughput and security of Nakamoto consensus by increasing the block frequency and utilizing fork blocks in the calculation of the total PoW weight of chains.

Single Forks and Virtual Blocks. In ProPoS, votes contribute to “weights” of chains and are crucial in the determination of the main branch. In short, they represent beliefs of stakeholders about their views of the main chain. For single forks, nodes follow the most-stake rule, i.e., the chain which is supported by more stake-weighted votes is chosen. ProPoS allows for no block to be added in a round (e.g., when a faulty node is elected as a leader or when the network is temporarily asynchronous) or a block that contains few or no votes. In such a case, nodes create a virtual block (see § III-B) which is a set of received votes that has not been included in the blockchain yet (virtual blocks do not have transactions or signatures, unlike ‘standard’ blocks). In the chain selection, nodes do not distinguish virtual from “standard” blocks and if a virtual block is stronger than some concurrent standard block, a voter will vote for the virtual block (indicating the latest standard block on the main chain as the previous one). A leader who does not include votes in her block may expect that the block will be overwritten by another leader aggregating these non-included votes present temporarily in virtual block(s).

Fig. 1: An example of a virtual block fork.

An example is presented in Fig. 1, where and voters in round publish seven votes supporting the block . The leader of round creates a block which includes only three votes with 4% of the stake. Therefore, a virtual block with 6% stake is created and in round all votes implicitly support this block (instead of ), thus the leader of this round creates a block that aggregates votes of the virtual block and pointing to . (We emphasize that the block includes also a pointer to cf. GHOST.)

Extension to Subtree Selection. When the network is synchronous (and is long) the proposed rule is likely to work well. But to achieve high throughput, the block delivery intervals have to be relatively short. This, combined with our Internet setting, would inevitably lead to asynchronous periods when blocks cannot reach nodes within the defined timeouts. Such a situation would result in a high stale block ratio that would inevitably decrease the security of the strongest chain.

In order to prepare the protocol to withstand such situations, we modify and extend GHOST to adapt it to our setting. The chain selection procedure is depicted in Alg. 3. As presented, the MainChain procedure starts at the genesis block. Then for each of its children blocks, the algorithm calculates the total stake (i.e., the votes associated with the given branch) of a child block’s subtree, and repeats this procedure for the child block with the most stake aggregated on its subtree, and so on. When the protocol terminates it outputs the block which denotes the last block of the main branch. The chain selection procedure relies only on the stake encoded in votes and collected votes of virtual blocks (i.e., not included in any actual block), and includes them in the total stake of their chain. Ties are broken in ProPoS by simply selecting the chain whose hash value computed over the concatenated round beacon and whose last leader’s public key is smaller.

1 function MainChain()
2        ;
3        while  do
4               if  then
5                      return ;
7              for  do
8                      ;
9                      if  then
10                             ; // stronger subtree found
15function TreeStake(root)
16        ;
17        for  do
18               ; // add stake directly supporting
20       return ;
Alg. 3 The chain selection procedure.
Fig. 2: Example of the blockchain evolution with many forks.

To illustrate the chain selection procedure we show an example in Fig. 2 where (for a simple presentation, in this and the following figures, the percentage within a block denotes the supporting stake included in that block). In our example, in round , the leader (i.e., the creator of block ) sees four chains, i.e., those ending with the blocks , , , and , respectively. To determine the main chain, the leader runs the protocol starting with the genesis block and computes the stake of its children’s subtrees. Block ’s subtree stake is whereas ’s subtree stake is . Thus, is selected and the leader repeats the same procedure for this block. Finally, the leader determines as the main chain, and creates a new block pointing to it. Moreover, the leader introduces pointers (dashed lines) to known but yet unreported fork blocks (). These pointers are required to preserve the integrity of the blockchain view. Note that the chain is selected as the main one, despite the fact that the stake that voted for this chain is lower than the stake of the chain . As different chains within a subtree support the same chain prefix, an advantage of combining GHOST with the most-stake rule is that it requires an adversary to compete with the entire subtree and not only its main chain, which makes attacks on safety much more difficult. Repeating the procedure, round ’s leader extends ’s chain and reports on fork blocks and .

Iii-E Block Commitment

Block commitment in ProPoS is decided by every client individually. A client specifies its risk level , the block to be committed , and given its current view of the blockchain calculates the probability that the target block can be reverted. Given our chain selection procedure, this question can be reformulated as follows: what is the probability that an adversary can create any stronger subtree than the corresponding subtree containing ? If the probability is less than the threshold , the block is committed.

An adversarial subtree has to be rooted at a block outside ’s supporting subtree, as otherwise, it would support . The stake of the supporting subtree is known to the client and computed simply by . An adversarial subtree can start in any previous round, so before the block can be committed, we require that all its previous blocks have also been committed. For each block, we hence consider the potential strength of an adversarial subtree that originates in the parent of and which has supporting blocks until the current round. As such, the supporting and adversarial branches are in competition during rounds. The client cannot determine how many stake units support an adversarial subtree, but this knowledge is critical for the security of the commit operation. Therefore, the client splits this stake into the sum of a) missing stakewhich consists of those stake units that may unknowingly contribute to the adversarial branch during a fork, and b) adversarial stakewhich is the sum of the stake that the adversary aggregated over the rounds.

The adversarial stake units can equivocate (being already part of the client’s blockchain view or even part of the supporting subtree) and their size is unknown, although on average their size will be equal to . We assume the worst-case scenario regarding the missing stake, i.e., that all missing stake (even if it is honest) is placed in an unknown adversarial subtree. That could happen during asynchronous periods or network splits. The client also conservatively assumes that the adversary would win every tie. However, we emphasize that an adversarial subtree has to be internally correct, e.g., cannot have equivocating votes within it, as otherwise, nodes seeing it would not accept that view (see App. E-A for a discussion on how ProPoS handles equivocating votes).

1 function Commit(lastCommit,)
2        ; while  do
3               ; ;
4               if  then // is rejected
5                      return;
6              ;
7               ;
10function CalculateProb(,)
11        if  MAX_STAKE then
12               return (,,,,);
13       return (,,,,);
14function HyperGeomProb(,,,,) // hypergeom. sum prob.
15        if  then
16               ; for  do
17                      ;
18              return ;
19       ; for  do
21                       ;
22       return ;
23function CCBound(,,,,) // the Cramér-Chernoff bound
24        return ;
25function MaximizeRateFunc(,,,)
26        ; repeat
27               for  do
28                      ;
29              ; ; // is an accuracy threshold set by the user
30       until ;
31       return ;
32function RateFuncHelper(,,,,)
33        return ;
Alg. 4 The block commitment procedure.

To commit , the client conducts a statistical hypothesis test to assert whether (most of) the network has the same view of the supporting tree as the client. That is, we compute a so-called -value that represents the probability of achieving a total supporting stake over rounds under the assumption that fewer stake units are contributing to the supporting branch than to the adversarial branch. We commit if this -value is so low that we can safely conclude that the assumption is invalid. The function Commit in Alg. 4 is called once every round, and as many blocks as possible are committed during every call. To achieve safety, we use the quorum intersection argument present in traditional BFT systems, except in our case it is probabilistic. Namely, an adversary in such a split network could produce equivocating votes on both views at the same time; however, the client can conclude that such a situation is statistically unlikely if she sees that her target block is supported by at least stake (see details in § IV-A). That would imply that most of the honest nodes see the target block on the main chain as any alternative adversarial view can obtain only less than over time (since ). The process is described by the pseudocode of Alg. 4. At the core of the procedure, the client keeps committing the main chain’s subsequent blocks computing the probability that their corresponding supporting trees are on the “safe” side of the hypothetical fork. Depending on the parameters, the probability is computed using one of two functions, namely or (see Alg. 4). In § IV-A, we discuss these algorithms in more detail and show that they indeed give an upper bound on the error probability. To illustrate this process we present an example in App. E-C.

To keep our presentation simple, we do not parametrize the commit procedure by the parameter. However, it would not change our methodology, and in practice, it may be an interesting feature as clients could then base commitment decisions on their own adversarial assumptions in addition to their security level .

Iii-F Random Beacon

ProPoS relies on random beacons to elect round leaders and voters. It is important for security that these beacons are (pseudo)random and difficult to be biased by adversaries. In this paper we do not propose a random beacon construction and for a concrete instantiation we rely on previously proposed concepts. For the current implementation, we have followed the approach by Daian et al. [16], where beacons are generated purely from the random values aggregated over “stable” blocks of the main chain. More precisely, as presented in § III-B, an -th round leader inserts a random value into its block. For the security parameter (the number of main chain’s blocks after which the probability of a roll back is negligible), the random beacon in the current round is extracted in a two-step process, using a random oracle, from the previous random values An adversary can bias the outcome beacon ; however, it has been proven in [16] that short-time adversarial biases in the randomness are insufficient to get a long-term significant advantage.

We emphasize that the use of a random beacon for leader/committee selection is not specific to ProPoS and other random beacon constructions can also be used to implement ProPoS. Some recent approaches, e.g., DFINITY [27] and RandHound [41], promise scalable randomness and are potentially more bias-resistant than the presented mechanism. We leave the investigation of these schemes combined with ProPoS as future work.

Iii-G Rewards

ProPoS introduces the rewarding scheme presented in Alg. 5. Each voter supporting the previous block of the main chain receives a voter reward multiplied by the number of stake units that the voter was sampled with. The votes of virtual blocks (i.e., when votes commit a chain whose the last leader did not publish its block) also receive rewards as soon as a block containing them is published. Every leader who publishes a block on the main chain receives a leader reward and an inclusion reward for every stake unit included in the block. Leaders may also receive transaction fees paid by clients but we omit them as they are application-specific.

1 function RoundReward(B)
2        ; // leader’s block reward (+ opt. tx fees)
3        for  do
4               ; // voter’s reward
5               ; // leader’s inclusion reward
Alg. 5 The reward procedure.

The rewarding scheme in ProPoS has several goals. First, it aims to incentivize voters to publish votes supporting their strongest views immediately. Forked or “late” votes (and blocks) are marked in main chain blocks, but they are not rewarded (leaders still have an incentive to include forked and late votes and blocks as they strengthen the main chain). Therefore, voters trying to wait for a few blocks to vote for “past best blocks” would always lose their rewards. Second, it incentivizes leaders to publish their blocks on time, as a block received after the end of the round would not be part of the main chain (i.e., voters of the next round would follow their strongest view instead), thus the leader would miss out on her rewards. Lastly, the scheme incentivizes block leaders to include all received votes. A leader censoring votes loses an inclusion reward proportional to the stake that was censored. Moreover, the censoring leader weakens her own blocks.

Iv Analysis

Iv-a Probabilistic Safety

In this section we show that a block is committed only if the probability that a conflicting block is committed is indeed below . To do this, we use a novel proof technique based on statistical hypothesis testing. A block is committed by a user when she sees enough supporting stake to conclude that it is unlikely that she is on a branch that includes only a minority of honest users. We consider an adversary who wants to cause a safety fault, which means that two conflicting blocks are committed by different users. For this to occur, two users who have different views of the blockchain must both see enough evidence for their blocks to commit. our worst-case scenario – i.e., scenario in which this is most likely to occur – is when the honest users are split during a fork. The adversary tries to make a safety fault more likely by voting on both branches of the fork simultaneously. Although equivocations can be punished in retrospect, this cannot be detected while the fork is ongoing and therefore cannot be ruled out for our safety analysis. We assume that a fraction of the stake is controlled by the adversary. We furthermore assume that the fork consists of two branches, and that the honest stake is split evenly among them. The reason is that if one branch is stronger than the other, then it is less likely that a block will ever be committed on the weaker branch. Similarly, there is no need to consider forks with three or more branches, because the probability of conflicting blocks being committed would be higher if two of the branches were combined. Finally, we do not consider users going offline or votes being withheld by the adversary, as this would only make one branch weaker and a safety fault less likely, and therefore represents a weaker adversarial scenario than the one under consideration. The user cannot directly observe how many users are on the two branches – however, she can observe how many stake units support the block on her branch. The expected stake fraction on her branch is , so if (this is the same for users on the other branch). If she observes that the amount of stake on her branch is considerably higher than this fraction, then she has evidence to conclude that her branch is stronger. In the following, we will formulate the question of whether there is sufficient evidence to commit as a hypothesis test. Before we proceed, we note that for to be committed, we require that all preceding blocks have also been committed. Hence, we only focus on and its supporting subtree, and do not consider any of ’s ancestors (see also the example in Fig. 3).

Recall that there are stake units of equal weight, where a single node may control many stake units. We draw a committee of size stake units in every round (e.g., in Fig. 3 it holds that ). We assume that and remain constant throughout the duration of the fork. We denote the number of expected supporting stake units per round on the user’s branch by . We also assume that does not change during the fork – i.e., that users do not move between branches while the fork is ongoing. We can make this assumption because the adversary is equivocating – the adversary is voting on both branches already, and if any of the honest users would move from one branch to the other then they would detect the equivocation. We assume that in a given round , the user is interested in testing whether the amount of stake that supports a block that appeared in round is enough to commit it. The null hypothesis asserts that the supporting stake is at most equal to the expected worst-case support, i.e.,


In the following, we compute the probability of observing a given amount of supporting stake in ’s subtree given that is true. This probability is commonly called a -value. If the -value is below , then we accept the alternative hypothesis and commit the block. Of course, this experiment may be repeated over the course of several slots until is finally committed (or if is dropped after the resolution of the fork). Hence, we use a sequential hypothesis test. In the following, we first focus on calculating the probability of observing the data (i.e., the supporting stake for the block ) given the null hypothesis for given rounds and , and then extend this to the sequential setting.

Fig. 3: If the user tries to commit , we only evaluate the strength of and its supporting subtree, and implicitly compare it to the branch . Even though is weak, and might be overturned due to a branch starting from ’s predecessor, we require that has already been committed before committing , so it need not be considered.

Let be the number of stake units held by supporting users sampled in round . Since the cryptographic sampling algorithm draws without replacement, we know that has a hypergeometric distribution [29], whose probability mass function is given by The total number of supporting units (where a single unit may feature in more than one different rounds) that is drawn in rounds is then given by Since are all identically distributed, this means that has the distribution of

independent hypergeometric random variables. Hence, to calculate the probability of observing a total amount of supporting stake

given the null hypothesis, we can compute the tail probability under the assumption that (of all possible values for included under , this would give the highest probability.) Unfortunately, a sum/convolution of hypergeometric random variables does not have a probability mass function that is easy to compute. It can be expressed as

This expression is derived in Lemma C.1 in the appendix. The intuition behind it is as follows: for all possible sequences , we calculate the probability of observing it, and then multiply this by the probability that is exactly minus the sum of the sequence. This is what is implemented in Alg. 4: the recursion encapsulates the repeated sum, while the final computation of is done in lines 4 through 4. Numerically, it can be simplified somewhat (i.e., it is not necessary to consider sequences whose sum already exceeds ). However, to compute this probability it is inescapable that the number of operations is roughly proportional to , which is very large even for moderate values of . This is the intuition behind the if-statement in line 4 of Alg. 4: the exact computation is only performed if is small enough, i.e., below some threshold that depends on the client’s processing power.

One less computationally expensive approach would to find an approximation for the distribution of . Good candidates include a single hypergeometric (with parameters , , and instead of , , and ), a binomial (for which we draw with instead of without

replacement), a Poisson (which approximates the binomial distribution), or a normally distributed (by the Central Limit Theorem) random variable. However, in the following we instead focus on establishing bounds using the Cramér-Chernoff method

[8]. The reasons for this are twofold. First, it gives us a strict upper bound on the probability of interest regardless of the parameter choice, which is safer than an asymptotically valid approximation. Second, it can be more easily generalized to settings where the distribution of the random variables is slightly different. We have also investigated other methods for bounding the tail probabilities of , e.g., the Chernoff-Hoeffding bound, and the approaches of [32] and [43]. However, the Cramér-Chernoff bounds were found to be the sharpest while still being computationally feasible.

The Cramér-Chernoff method can be used to find an upper bound on the probability for any random variable . Its basis is Markov’s inequality,333’s_inequality which states that for any nonnegative random variable and , It can then be shown [8] that for any , where . Since this holds for all , we can choose such that the bound is sharpest. Let then In particular, if , such that all ,

are mutually independent and have the same probability distribution as

, then and hence and therefore Common names for include the Legendre-Fenchel transform444Strictly speaking, only after broadening the range of the supremum. or the large-deviations rate function of after its use in Cramér’s theorem for large deviations.555ér’s_theorem_(large_deviations) In our context, is the average supporting stake accumulated per round. As shown in Lemma C.3 in the appendix, if is higher than the expected worst-case supporting stake (which equals ), then the probability that the adversary wins decreases exponentially in . In fact, the function represents the exponential rate at which this probability decreases (hence the name “rate function”).

As an example, let , , and . We find that . This means that the probability under the null hypothesis that we observe an average support of of the committee for rounds in a row decreases at least exponentially with a factor of per round. This is displayed in Fig. 4, for . After 15 rounds, the probability of observing support from, on average, of the committee is less than under .

The function does not have a convenient closed-form expression: it is equal to [45], where is the Gaussian or ordinary hypergeometric function.666 Hence, the rate function has to be evaluated numerically. Since is convex on (see also Lemma C.2 in the appendix), there is only one local optimum and we can therefore use some variation of golden-section search777 to find it. The procedure in Alg. 4 is as follows: we first determine a search range for by widening a base interval until we observe that the function decreases at some point in the interval. We then iteratively narrow the interval until its width is below some accuracy threshold. A baseline implementation is given in Alg. 6 in the appendix. Computation of the rate function is still not trivial, although it depends on the size of : for , roughly instances can be computed per second on a MacBook Pro with a 2.5 GHz Intel Core i7 processor, compared to for and for . Still, although there is no theoretical limit on the number of blocks that can be committed in a single round via the Commit function in Alg. 4, in practice it is unlikely that more than several blocks are committed in a single round, as the evidence for committing is accumulated slowly.

Fig. 4: The Cramér-Chernoff bound for the probability that a block is overturned, assuming that , and its supporting subtree in each of the subsequent rounds, contain stake units. In these figures, , , and varies. Clearly, when the committee size grows larger, the probability that the supporting stake is substantially larger than the expected value under the null hypothesis vanishes.

Fig. 4 depicts the evolution of the bounds if the same average supporting stake is observed over rounds consecutively. It is clear that, as expected, larger committee sizes mean that large deviations are less likely, and therefore that the user is able to commit sooner. Hence, there is a trade-off between security and efficiency. Even if and on average 24 stake units vote to support a block, then the -value decreases by almost per round (i.e., ).

Although we have so far focused on a single test conducted in round about a block in slot , in practice the test for will be performed multiple times if there is not enough evidence to commit immediately. Every time the test is performed, there is some probability of error, so we need to account for this accumulation. The most straightforward way to achieve this is as follows: if we conduct the test for the th time, we use for some as our threshold. The total probability of error after a potentially infinite number of trials is then . For example, if , then we need to multiply our probability threshold by (e.g., if we originally had set a threshold of then we would now use ), and the threshold for the -value would become lower (so harder to meet) by each round. This is not a major obstacle: as mentioned before, even for a committee size of and an average supporting stake of , the -value decreases considerably faster than by per round, and the multiplicative factor of is met after only 2 additional rounds.

The conclusions that we can draw from our analysis are as follows. If two honest users on separate branches are performing the same experiment, and the honest stake is split evenly between the two branches, then the probability that both users commit is (or even lower if there is negative correlation between the stake on the two branches, which is the case if the implementation of the random beacon is such that the same committee is chosen for different blocks in the same round), so this is much lower than . In the case where the stake is not evenly split among the two branches, then if the user is on the weaker branch, the probability that she ever commits is below . If the user is instead on the stronger branch, then the probability that the honest users on the weaker branch ever commit is below . Hence, the probability of both and a conflicting block being committed is below in all settings. Our safety property is therefore satisfied.

Long-range Attacks. Our safety analysis also naturally extends to non-trusted checkpointing as an additional defense. Namely, if a block has so many confirmations that the probability of overturning it is lower than some pre-defined negligible threshold (e.g., ), then it is reasonable for a client to consider this block as a checkpoint. Hence, the client would never revert this block except in the case of a manual reset, mitigating long-range attacks. (In App. E-A we also discuss other measures deployed by ProPoS to disincentivize adversaries from equivocating on the blockchain.)

Iv-B Liveness

In our analysis we assume the partially synchronous network model, where after the GST the network is synchronous for rounds. We follow the same setup in § IV-C and § IV-D. To prove liveness we use two lemmas (see App. D). In short, they state that with increasing , after rounds, a) the main chain includes at least stake units (Lemma D.1), and b) the main chain includes blocks that the honest participants voted for, where (Lemma D.2).

Theorem IV.1.

ProPoS achieves liveness.


We show that the probability that within rounds an honest node appends a block to the main chain and the block is committed by every honest node is overwhelming, with increasing.

By using Lemma D.2, we obtain that the (increasing proportionally with ) blocks of the main chain were supported (thus visible) by honest majority. Now, to violate liveness, the adversary has to be elected as a leader for all of those contributed rounds.888In such a case the adversary could append blocks with no transactions, append them to a different (weaker) fork, or not publish them at all. The adversary is elected as a round leader with the probability proportional to her stake possession . Therefore, the probability that at least one honest node adds a block in those visible rounds is , which with increasing goes to .

Now, after the first rounds, the block will be on the main chain, thus honest nodes over the next rounds will be supporting the block by their stake of the total amount at least units (see Lemma D.1) with increasing. We assume that , which means that there exists some such that . This means that the expected amount of supporting stake per round will be

, even if the adversarial nodes never vote. By the weak law of large numbers, the probability that the average supporting stake after

rounds is not above goes to zero as goes to infinity. We know by Lemma C.3 that if the observed average supporting stake is greater than the mean, the rate function evaluated at this average is greater than 0. By substituting the threshold into (3), we learn that , and that the expected per-round supporting stake under the null hypothesis equals at most . Since we therefore observe more than the mean under the null hypothesis on average, the per-round decay rate will be greater than 1, and the upper bound on the test -value goes to as goes to infinity. As such, there will be some at which the -value goes below , which means that the user can commit. This completes the proof for liveness. ∎

In practice, the required length of depends on the values of , , , and , and can be directly derived from the bound given in § IV-A.

Iv-C Fairness

Let us define as the total expected reward of an honest node with stake fraction during synchronous rounds after GST. Next we show that ProPoS is a fair protocol.

Theorem IV.2.


Every round (see Alg. 5), a node has the expected voter’s reward and the expected leader’s reward of (contributions of inclusion rewards may vary and in the worst case can be ). As shown in Lemma D.2, honest nodes participate in blocks of the main chain during rounds, with growing proportional to . We assume that an adversary can censor the node’s votes (removing her voter rewards) but that will not happen in rounds on average (i.e., when an honest leader is elected). Thus and given the bounds for (Lemma D.2), the following holds

Another advantage of our reward scheme is that it rewards active nodes frequently. In every round, stake units are awarded as voter rewards and one leader obtains leader rewards. The rewards are given uniformly at random and proportional to stake possession. In an example setting where , , , even a node with a small stake possession would receive a voter reward every 50 rounds and a leader reward every rounds, on average. With a realistic round time , this would be 250 seconds and 13.9 hours, respectively. By contrast, systems that award only leaders would not give these frequent voter rewards. For instance, in Bitcoin (where only leader awards exist and rounds last 10 minutes on average) the node would receive a reward every 70 days on average. By combining frequent rewards with fairness (Theorem IV.2), ProPoS minimizes the reward variance which is seen as the root cause of creating large mining pools which introduce centralization into the system.

Iv-D Rewards and Incentives

To reason about rewards in ProPoS, we use a definition similar to the one by Pass and Shi in [37]. We call a protocol’s reward scheme -coalition-safe if, with overwhelming probability, no fraction coalition can gain more than a multiplicative factor (1 + ) of the total system rewards. Intuitively, it means that with overwhelming probability, for any coalition of nodes, the fraction of their rewards (within a time period) is upper-bounded by , while a solo node is guaranteed to receive at least . Thus, the multiplicative increase in the reward is .

Using this definition, we show how relationships between rewards in ProPoS influence its coalition-safety. As shown in Theorem IV.2, the total reward of a node with stake fraction during synchronous rounds is between and . Thus and the following holds: . We also have owing to , resulting in

As we want to minimize and , owing to and , we wish to minimize and , thus, should be large enough to make and smaller, i.e., and .

We suggest that is higher than . The intuition behind this choice is that as voter rewards are received frequently when compared with inclusion rewards received only by a leader. A too high would contribute to a high reward variance and could incentivize nodes to join their stake into pools (as in PoW systems), introducing centralization risks. Therefore, with , we propose the following relationships between rewards in ProPoS:  

Our rewarding scheme (§ III-G), aims to incentivize a) voters to broadcast their votes immediately, b) leaders to broadcast their blocks immediately, and c) leaders to include all received votes in their blocks. We informally reason about its incentive-compatibility in a setting with synchrony, a single leader elected per round, and rational nodes (optimizing only for their rewards). If a voter does not publish its vote on time, it will not reach the round’s leader, who subsequently cannot include this vote in her block, thus the voter loses her reward . Similarly, if the leader does not publish her block immediately, it is not received by other nodes, who in the next round will vote for a virtual block, ignoring the late block and hence not awarding the rewards and to the leader. If the leader publishes blocks but without some of the received votes, then the leader is losing the inclusion reward proportional to the stake of the ignored votes.

Iv-E Scalability and Parametrization

In order to evaluate how different configurations influence ProPoS’s performance and security, we have built a ProPoS simulator and conducted a series of experiments. For our simulations, we introduced 5000 active nodes with one stake unit each (thus ) and a single leader per round (

). (The number of nodes is comparable with the estimated number of all active Ethereum nodes 

[20].) To model the network latencies while propagating messages we used the data from, which in real-time collects various information (like the block propagation time) from volunteer Ethereum nodes. In this setting, we ran simulations for different values of and , where each simulation run was for 10000 blocks. We measured the block and vote stale rates and , which respectively describe how many blocks and votes do not make it onto the main chain.

Fig. 5: Simulated stale rates.

The obtained results are presented in Fig. 5. We see that if is too short, then protocol performance decreases as stale rates for both blocks and votes are high. Besides influencing performance (fewer blocks denote lower throughput), high stale rates degrade security as it takes longer to commit a block (see § IV-A). However, when is slightly increased, the stale rates improve significantly. We found that choosing between 3-4 seconds may be good for the considered network conditions. We confirm our results in § V. Moreover, with increasing , we see only a mild increase in the stale rates.

V Implementation and Evaluation

Implementation. To test and evaluate ProPoS we fully implemented it. Our implementation is based mainly on Python. For implementing the p2p networking stack, we use the Twisted framework while we deployed Ed25519 signatures [5]. The advantage of this scheme is that is produces short public keys and signatures (32 and 64 bytes, respectively). In our implementation, we have encoded a vote in 80 bytes, and votes are included within their respective blocks. Although the number of votes is linear, even for large values of the introduced bandwidth overhead should be acceptable. For instance, 1000 support votes with our encoding would consume 80kB, which constitutes only 4% of a 2MB block. Furthermore, in future ProPoS implementations, votes can be realized by threshold signatures giving a short constant-size group signature; however, these schemes would currently be a bottleneck in our scheme.

Evaluation. Equipped with our implementation we conducted a series of experiments in a real-world setting. We set up a testbed consisting of physical machines geographically distributed among 15 different locations from five continents. We used these machines to run 100 ProPoS nodes in total. We used a simple p2p flooding where every node peered with up to five peers. We first investigated the throughput of the network and we obtained an average end-to-end throughput of around 10 Mbps. To introduce a conservative setting and better express real-world heterogeneous network conditions we did not optimize our network by techniques like efficient message dissemination or geographical peer selection.

We decided to deploy 2MB blocks on our network. In our setting, all our 100 nodes are elected as voters (i.e., ) while only one node per round is elected as leader. From the performance point of view, such a setting would be for instance equivalent to the setting when there are 2000 nodes in the system and . During the execution of our experiments, we noticed an imbalance between the durations of the protocol steps. Namely, votes constitute only a small part of the blocks that actually carry transactions, so if the nodes spend too much time waiting for votes (the same is specified as the waiting time for both votes and blocks), then this would not allow us to saturate the network. To maximize the throughput we introduced separate waiting times for votes and blocks (i.e., and respectively, where ).

We have run a series of experiments with different and parameters and our results are presented in Tab. I. Namely, we measure the following three performance indicators: the block and vote stale rates ( and as defined in § IV-E) and the number of transactions per second (tps) that our protocol achieves in a given setting.999We assumed 150B-long transactions, that, using the Ed25519 signature scheme, allows us to encode sender and receiver public keys (32B each), a signature (64B), and some transaction metadata (22B). We found and as a promising configuration for our setting. With these parameters, all blocks were part of the main chain and their propagation time (i.e., ) allowed voters to produce only 5% of stale or missing votes. Moreover, even in this conservative setting ProPoS yielded throughput of almost 2.5k tps.

(%) (%) tps
1.0 4.0 14.3 33.5 2286
3.0 3.0 2.5 22.3 2167
2.0 3.0 0 23.0 2667
2.5 3.0 0 20.6 2058
2.0 4.0 0 5.4 2222
1.5 4.0 0 5.3 2424
Tab. I: The performance results obtained.

Vi Comparison to Algorand

In this section we compare ProPoS to Algorand [26], which is a closely-related PoS protocol. Algorand is similar to ProPoS in the sense that 1) the protocol operates as a sequence of rounds, 2) leaders and committee members are selected in each round based on a random beacon that changes between rounds, 3) the likelihood that a node is selected as a leader or committee member is proportional to its number of stake units, 4) committee members vote on blocks proposed by the leaders, and 5) blocks are committed if they receive a sufficient number of votes. However, there are also two crucial differences. The first is that instead of the cryptographic sampling procedure of Alg. 2, Algorand elects leaders and committee members in every round by running a VRF [34] over the round’s random beacon. As a result, the number of leaders and committee members in each round is random instead of fixed, and as we show the added variance makes block commitment less secure. Second, instead of the voting and sequential hypothesis testing procedures of Alg. 1 and 4, Algorand uses a bespoke Byzantine agreement protocol (BA) to commit blocks. However, BA includes many steps during which no transactions are added to the blockchain, and the security analysis for BA is more restricted than for ProPoS. There are other differences (e.g., rewards and fairness are not discussed in [26]), but due to space restrictions we only elaborate on the two main differences. We first discuss some of Algorand’s technical details that we need for our comparison.

Vi-a Technical Discussion of Algorand

In each round of Algorand, each node uses a VRF with the user’s private key to calculate a hash of the random beacon concatenated with a “role” index. Each round in Algorand consists of two phases, and there are three roles: block proposer, initial (“step”) committee member, and final committee member. The value of the calculated hash determines how many of the node’s stake units qualify for each role. For any node, let be the number of stake units that it controls, and be the number of stake units that are assigned to a given role. Alg. 1 of [26] then ensures that is binomially distributed with where is the probability for each single stake unit that it is assigned to role. The probabilities are chosen such that the expected total numbers of block proposers, initial committee members, and final committee members per round equal , , and , respectively. Each leader proposes a block such that there is a priority relation between the proposed blocks that is obvious to all nodes. The committee members wait a fixed amount of time per round () to receive blocks. Next, they initiate Phase 1 in which they vote for the highest-priority block that they are aware of (Alg. 7 of [26]). If a block receives more than votes across two rounds of voting (“steps”), it advances to Phase 2. Phase 2 (Alg. 8 of [26]) consists of a sequence of steps in which the initial committee members either vote for the block from Phase 1 or an empty block. If either option receives more than votes during a step, it is subjected to a final vote among the final committee members. If the block receives more than votes in the final vote, then it is committed by the nodes. Each step in either phase of BA takes time units. The Algorand white paper provides a set of of benchmark parameters for BA (see Fig. 4 of [26]) to ensure that the probability of a safety fault is sufficiently small (less than over 1000 rounds) if the adversary controls at most of the stake: seconds, seconds, , , , , and .

Vi-B Random vs. Fixed Committee Sizes

We first investigate what the impact would be if Alg. 2 of ProPoS were replaced by Algorand’s committee selection procedure, so that and are no longer fixed. The main consequence is that the additional variance due to the committee sizes makes it harder to make block commitment decisions using hypothesis testing. This difference in terms of variance is made explicit in Tab. II of App. E-E. In particular, the quantity of supporting stake per round was previously hypergeometric (drawing samples without replacement from a population of size of which support the user’s branch), whereas in the setting with VRFs it is binomial with a considerably larger population size (drawing samples such that each is in the committee with probability and supportive of the user’s branch with probability ). The variance is typically around 3-4 times higher in the new setting if the adversary controls one third of the stake (i.e., ). As we can see from Fig. 6, this translates into block commitment times that are also roughly 3-4 times higher. For this experiment, we calculated numerically for different values of the average supporting stake per round how many rounds it would take to commit in a setting where , , , , and (as discussed in § IV-A). If is binomially distributed, then is also binomially distributed, so we do not need to use the Cramér-Chernoff method to bound the probability for the VRF setting because we can calculate it directly. However, the looseness of the Cramér-Chernoff bound is clearly offset by the VRF method’s higher variance. It can also be seen that if is high enough, then ProPoS can commit the blocks very quickly. For example, if is at least equal to , then the protocol can commit within 3 rounds despite the very high security requirement (i.e., a safety error probability per round of ). As long as is above , ProPoS can commit within 10 rounds – with 5.5 seconds per round (see Tab. I), this is still only 55 seconds and therefore much less than the (on average) hour for 6 confirmations in Bitcoin.

Fig. 6: Number of rounds needed before a block can be committed given an average supporting stake fraction per round for fixed committee sizes (ProPoS) and VRFs. It takes around 3-4 times longer to commit using VRFs.

Vi-C Hypothesis Testing vs. Byzantine Agreement

Although the use of VRFs increases the number of rounds needed to commit a block using hypothesis testing, the value proposition of Algorand’s BA algorithm is that it can commit blocks within a single round. However, there are several important caveats. The first is that even in the best-case scenario, the two phases of BA take 2 steps each, so a round in Algorand takes at least 85 seconds, which is the same as 15 rounds of ProPoS. No transactions are added during the BA steps, whereas in ProPoS transaction-containing blocks are confirmed by other transaction-containing blocks. The second is that the security analysis relies on larger committee sizes (10,000 stake units in the final round) and a weaker adversary (who only controls of the stake) than ProPoS. Finally, each user in ProPoS is able to set her security threshold individually depending on her risk tolerance, whereas Algorand has a fixed set of security parameters that determine block commitment.

Vii Other Related Work

Because of space limits, we discuss only the most related systems and we refer readers to recent surveys [13, 2, 36] for a more complete picture. Initial PoS protocols tried to extend or modify Nakamoto’s consensus by taking stake into consideration, resulting in hybrid PoS-PoW systems [31, 4], later improved by pure PoS systems. Bentov et al. propose a protocol [3] where nodes who commit to the chain generate randomness for a given round. While the randomness is generated it is used to coordinate the extension of the blockchain in the next several rounds. Other PoS protocols [21, 44] try to emulate the mining process of Nakamoto Consensus by using unique digital signatures. All these systems aim to remove the energy waste of Bitcoin; however, they share multiple other drawbacks of Nakamoto consensus, like slow (probabilistic) finalization, a tendency to centralization via high reward variance, or high stale block rates (due to a probabilistic leader election).

Another class of PoS systems is protocols where a committee is elected and involved in the process of blockchain extension. In Ouroboros [30], a committee is formed in every round from the stakeholders. The committee members run a three-phase leader election protocol that requires strong synchronization. Ouroboros is presented using a synchronous network model and this assumption is relaxed by Ouroboros Praos [17], which is presented using a partially synchronous network model. It also extends its predecessor by mitigating adaptive corruptions via a VRF-based election and by employing key-evolving signatures to achieve forward security (i.e., an adversary compromising a node cannot use its private key for signing older messages). Further, this protocol is improved by Ouroboros Genesis [1], the current version of the protocol, which proposes a chain selection rule that allows newcomers or offline parties to securely join the protocol. Ouroboros shares the limitations of longest-chain PoS protocols as reported by Brown-Cohen et al. [10] (we discuss this result later in this section). Moreover, the protocol leaves rewards and incentives as future work. In particular, we believe that Ouroboros, by using a block structure similar to Bitcoin (i.e., a single voting entity per block), would introduce high reward variance. Up to our best knowledge, in all widely deployed blockchain systems with similar design, this was one of the reasons that have inevitably led to centralization of voting power around mining/stake pools [24]. In fact, Cardano, a cryptocurrency built upon Ouroboros, encourages users to either join or create stake pools [39].

Snow White [16] is another longest-chain PoS protocol in which in every round a block proposer is elected (pseudorandomly) from a reconfigurable committee. An important advantage of Snow White, in contrast to other committee-based protocols, is that it is designed for network conditions including temporal asynchronicity and network partitions, or the “sleepy” model of node participation [38]. Moreover, Snow White proposes a chain-based beacon generation (we use this method as the default random beacon in ProPoS), and secure committee reconfiguration and leader election procedures that mitigate some adaptive adversaries.

Tendermint [33] is a PoS protocol inspired by traditional BFT protocols. Tendermint elects leaders using round-robin and a committee in a (pseudo)random way, proportional to nodes’ stake possession. The committee members run a BFT-like protocol to agree on the proposed block. To avoid attacks on leaders (round leaders are known in advance) it proposes a lightweight network-level anonymity solution. Casper FFG [11] is a PoS system designed to provide finality for underlying PoW or PoS blockchains. Casper is also inspired by traditional BFT protocols; however, its main observation is that BFT-like logics can be encoded as a sequence of messages of the same type. Casper is designed for an open setting, enabling a dynamic set of nodes and incentive-based protection against equivocation (misbehaving nodes risk losing their deposits), but it shares the scalability limitations of traditional BFT protocols. Under the Ethereum 2.0 roadmap, Casper FFG is planned to provide finality first to the legacy PoW and later a novel PoS chain that includes sharding. Development of the block proposal mechanism on the PoS chain is ongoing, but the stable parts of the protocol share similarities with ProPoS. For example, it is also chain-based, with attestations taking the place of votes in the fork-choice rule. Also, in the current version of the spec, committees are selected by cryptographic sampling using one of the techniques of [28].

Brown-Cohen et al. [10] analyze longest-chain PoS protocols and show their fundamental limitations in preventing PoS-specific attacks. For example, it formalizes local predictability, allowing leaders in self-elected protocols efficiently predict how long “secret” chains they can create. The paper reports findings regarding multiple mentioned PoS schemes, including Snow White and Ouroboros. These results do not directly apply to our work, however. The chain selection in ProPoS fully depends on votes (and not leader-driven chain length) and on the employed GHOST-like rule which cannot be expressed in the proposed framework (both these design choices are admitted by the authors of this study as its limitations). An adversary in ProPoS can try to create a secret branch by predicting her voting stake in subsequent rounds. Our methodology presented in § IV-A captures such attacks, and as shown, even their stronger variants (with the worst-case network split) have negligible success probability.

Viii Conclusions

In this work we have proposed ProPoS, a novel PoS consensus protocol dedicated to cryptocurrencies. Surprisingly, through its simple construction ProPoS provides a robust, scalable, and secure consensus mechanism. Our scheme extends the notion of probabilistic safety, such that clients base block commitment decisions on the probability of the block being reverted given the total observed support for it. These decisions are made more precise thanks to a lightweight committee voting scheme that allows large numbers of nodes to participate and express their beliefs about the blockchain.

In this work we have presented the core concept behind ProPoS and its properties. In the future, we plan to extend and analyze the system in a more dynamic setting and with adaptive adversaries. In particular, we believe that the ideas that are present in recent protocols [26, 16, 17] can be successfully applied in ProPoS, enhancing the protocol further. Another interesting research problem is to find an efficient election protocol combining the advantages of the proposed schemes (i.e., “secret” but deterministic election). We also plan to study further economic aspects of the reward scheme and their influence on the security of the system.


This project is supported by by the Ministry of Education, Singapore, under its MOE AcRF Tier 2 grant (MOE2018-T2-1-111).


  • [1] C. Badertscher, P. Gaži, A. Kiayias, A. Russell, and V. Zikas (2018) Ouroboros genesis: composable proof-of-stake blockchains with dynamic availability. In ACM CCS, Cited by: §VII.
  • [2] S. Bano, A. Sonnino, M. Al-Bassam, S. Azouvi, P. McCorry, S. Meiklejohn, and G. Danezis (2019) SoK: consensus in the age of blockchains. In ACM AFT, Cited by: §VII.
  • [3] I. Bentov, A. Gabizon, and A. Mizrahi (2016) Cryptocurrencies without proof of work. In Financial Crypto, Cited by: §VII.
  • [4] I. Bentov, C. Lee, A. Mizrahi, and M. Rosenfeld (2014) Proof of activity: extending bitcoin’s proof of work via proof of stake.. IACR ePrint. Cited by: §VII.
  • [5] D. J. Bernstein, N. Duif, T. Lange, P. Schwabe, and B. Yang (2012) High-speed high-security signatures. Journal of Cryptographic Engineering 2 (2). Cited by: §V.
  • [6] S. Bojja Venkatakrishnan, G. Fanti, and P. Viswanath (2017) Dandelion: redesigning the bitcoin network for anonymity. ACM POMACS 1 (1). Cited by: §E-B.
  • [7] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten (2015) Sok: research perspectives and challenges for bitcoin and cryptocurrencies. In IEEE SP, Cited by: §I.
  • [8] S. Boucheron, G. Lugosi, and P. Massart (2013) Concentration inequalities: a nonasymptotic theory of independence. Oxford university press. Cited by: §IV-A, §IV-A.
  • [9] E. A. Brewer (2000) Towards robust distributed systems. In PODC, Cited by: §I.
  • [10] J. Brown-Cohen, A. Narayanan, A. Psomas, and S. M. Weinberg (2019) Formal barriers to longest-chain proof-of-stake protocols. In ACM EC, Cited by: §I, §VII, §VII.
  • [11] V. Buterin and V. Griffith (2017) Casper the friendly finality gadget. arXiv. Cited by: §E-A, §E-D, §VII.
  • [12] V. Buterin, D. Reijsbergen, S. Leonardos, and G. Piliouras (2019) Incentives in Ethereum’s hybrid Casper protocol. IEEE ICBC. Cited by: §E-A.
  • [13] C. Cachin and M. Vukolić (2017) Blockchain consensus protocols in the wild. arXiv. Cited by: §VII.
  • [14] M. Castro, B. Liskov, et al. (1999) Practical Byzantine fault tolerance. In OSDI, Cited by: §I.
  • [15] K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, A. Miller, P. Saxena, E. Shi, E. G. Sirer, et al. (2016) On scaling decentralized blockchains. In Financial Crypto, Cited by: §I.
  • [16] P. Daian, R. Pass, and E. Shi (2019) Snow white: robustly reconfigurable consensus and applications to provably secure proofs of stake. In Financial Crypto, Cited by: §III-F, §VII, §VIII.
  • [17] B. David, P. Gaži, A. Kiayias, and A. Russell (2018) Ouroboros Praos: an adaptively-secure, semi-synchronous proof-of-stake blockchain. In EUROCRYPT, Cited by: §VII, §VIII.
  • [18] J. R. Douceur (2002) The sybil attack. In International workshop on peer-to-peer systems, Cited by: §II.
  • [19] C. Dwork, N. Lynch, and L. Stockmeyer (1988) Consensus in the presence of partial synchrony. Journal of the ACM (JACM) 35 (2). Cited by: §II, §II.
  • [20] Ethereum mainnet statistics. Note: Cited by: §IV-E.
  • [21] L. Fan and H. Zhou (2017) A scalable proof-of-stake blockchain in the open setting (or how to mimic nakamoto’s design via proof-of-stake). Technical report IACR ePrint. Cited by: §VII.
  • [22] G. Fanti, L. Kogan, S. Oh, K. Ruan, P. Viswanath, and G. Wang (2019) Compounding of wealth in proof-of-stake cryptocurrencies. In Financial Crypto, Cited by: §E-D, §I.
  • [23] G. Fanti, S. B. Venkatakrishnan, S. Bakshi, B. Denby, S. Bhargava, A. Miller, and P. Viswanath (2018) Dandelion++: lightweight cryptocurrency networking with formal anonymity guarantees. ACM POMACS 2 (2). Cited by: §E-B.
  • [24] A. E. Gencer, S. Basu, I. Eyal, R. Van Renesse, and E. G. Sirer (2018) Decentralization in bitcoin and ethereum networks. In Financial Crypto, Cited by: §VII.
  • [25] A. Gervais, G. O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf, and S. Capkun (2016) On the security and performance of proof of work blockchains. In ACM CCS, Cited by: §I.
  • [26] Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich (2017) Algorand: scaling byzantine agreements for cryptocurrencies. In ACM SOSP, Cited by: §E-E, §I, §VI-A, §VI, §VIII, 7.
  • [27] T. Hanke, M. Movahedi, and D. Williams (2018) Dfinity technology overview series, consensus system. arXiv. Cited by: §III-F.
  • [28] V. T. Hoang, B. Morris, and P. Rogaway (2012) An enciphering scheme based on a card shuffle. In CRYPTO, Cited by: §VII.
  • [29] N. L. Johnson, A. W. Kemp, and S. Kotz (2005) Univariate discrete distributions. John Wiley & Sons. Cited by: §IV-A.
  • [30] A. Kiayias, A. Russell, B. David, and R. Oliynykov (2017) Ouroboros: a provably secure proof-of-stake blockchain protocol. In CRYPTO, Cited by: §VII.
  • [31] S. King and S. Nadal (2012) Ppcoin: peer-to-peer crypto-currency with proof-of-stake. Cited by: §VII.
  • [32] A. Klenke and L. Mattner (2010) Stochastic ordering of classical discrete distributions. Advances in Applied probability 42 (2). Cited by: §IV-A.
  • [33] J. Kwon (2014) Tendermint: consensus without mining. Cited by: §VII.
  • [34] S. Micali, M. Rabin, and S. Vadhan (1999) Verifiable random functions. In IEEE FOCS, Cited by: §E-E, §VI.
  • [35] S. Nakamoto et al. (2008) Bitcoin: a peer-to-peer electronic cash system. Cited by: §I.
  • [36] C. Natoli, J. Yu, V. Gramoli, and P. Esteves-Verissimo (2019) Deconstructing blockchains: a comprehensive survey on consensus, membership and structure. arXiv. Cited by: §VII.
  • [37] R. Pass and E. Shi (2017) Fruitchains: a fair blockchain. In ACM PODC, Cited by: §IV-D.
  • [38] R. Pass and E. Shi (2017) The sleepy model of consensus. In International Conference on the Theory and Application of Cryptology and Information Security, Cited by: §VII.
  • [39] Shelley incentivized testnet - cardano. Note: Cited by: §VII.
  • [40] Y. Sompolinsky and A. Zohar (2015) Secure high-rate transaction processing in bitcoin. In Financial Crypto, Cited by: §III-D.
  • [41] E. Syta, P. Jovanovic, E. K. Kogias, N. Gailly, L. Gasser, I. Khoffi, M. J. Fischer, and B. Ford (2017) Scalable bias-resistant distributed randomness. In IEEE SP, Cited by: §III-F.
  • [42] P. Szalachowski, D. Reijsbergen, I. Homoliak, and S. Sun (2019) StrongChain: transparent and collaborative proof-of-work consensus. In USENIX Security, Cited by: §III-D.
  • [43] K. Teerapabolarn (2015) Binomial approximation for a sum of independent hypergeometric random variables. Global Journal of Pure and Applied Mathematics 4 (5). Cited by: §IV-A.
  • [44] X. Wang, G. Kamath, V. Bagaria, S. Kannan, S. Oh, D. Tse, and P. Viswanath (2019) Proof-of-stake longest chain protocols revisited. arXiv. Cited by: §VII.
  • [45] D. Zwillinger and S. Kokoska (2000) CRC standard probability and statistics tables and formulae. CRC Press. Cited by: §IV-A.

Appendix A Cryptographic Sampling Proof

We show that no probabilistic polynomial-time (PPT) adversary can distinguish outputs of our cryptographic sampling (see § III-C) from truly random sampling.

Definition 1 (Pseudorandom sampling).

is a pseudorandom sampling and mapping if it is collision-resistant and satisfies the following requirements: 1. For any , is a bijection from to . 2. For any , there is an efficient algorithm to evaluate . 3. For all probabilistic PPT distinguishers :

where is chosen uniformly at random and is chosen uniformly at random from the set of permutations on -bit strings.

Corollary 1.

If the output of

is indistinguishable from the uniform distribution, then the result of

for any is indistinguishable from the uniform distribution.

In particular, a pseudorandom sampling family is a collection of pseudorandom functions, where a specific sampling may be chosen using a key as a salt.

Lemma A.1.

We say that is an unpredictable pseudorandom sampling, if no PPT adversary can distinguish the unit-pair from a uniform random distribution.


For all PPT distinguishers :

In other words, a PRF is any pseudorandom hash function that can be used to map data of arbitrary size to data of fixed size, and the above equation implies that if the PRF is secure, then its output is indistinguishable from random output.

We define the following two distributions. is the distribution , where