Weighted Voting on the Blockchain: Improving Consensus in Proof of Stake Protocols

by   Stefanos Leonardos, et al.

Proof of Stake (PoS) protocols rely on voting mechanisms to reach consensus on the current state. If an enhanced majority of staking nodes, also called validators, agree on a proposed block, then this block is appended to the blockchain. Yet, these protocols remain vulnerable to faults caused by validators who abstain either accidentally or maliciously. To protect against such faults while retaining the PoS selection and reward allocation schemes, we study weighted voting in validator committees. We formalize the block creation process and introduce validators' voting profiles which we update by a multiplicative weights algorithm relative to validators' voting behavior and aggregate blockchain rewards. Using this framework, we leverage weighted majority voting rules that optimize collective decision making to show, both numerically and analytically, that the consensus mechanism is more robust if validators' votes are appropriately scaled. We raise potential issues and limitations of weighted voting in trustless, decentralized networks and relate our results to the design of current PoS protocols.



There are no comments yet.


page 1

page 2

page 3

page 4


Scaling Blockchains: Can Elected Committees Help?

In the high-stakes race to develop more scalable blockchains, some platf...

AlphaBlock: An Evaluation Framework for Blockchain Consensus Protocols

Consensus protocols play a pivotal role to balance security and efficien...


We introduce Casanova, a leaderless optimistic consensus protocol design...

An Uncertainty- and Collusion-Proof Voting Consensus Mechanism in Blockchain

Though voting-based consensus algorithms in Blockchain outperform proof-...

Positionality-Weighted Aggregation Methods on Cumulative Voting

The issue in solving social problems is how to respect minority opinions...

Efficient democratic decisions via nondeterministic proportional consensus

Are there voting methods which (i) give everyone, including minorities, ...

Between Discord and Deadlock: Consensus Under a Deadline

Committees are an important scenario for reaching consensus. Beyond stan...
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

In Proof of Work (PoW) or Nakamoto consensus[35], a single miner claims the right to append the next block to the blockchain after solving a secure cryptographic puzzle. The strengths and vulnerabilities of this mechanism have been studied and understood, see [23, 25, 24] and [22, 28, 43]. Two fundamental properties satisfied by PoW are the following: (i) Miners holding of computational power will create on average of blocks that will be part of the blockchain assuming that all miners follow the protocol. This property relies on the randomness of the cryptographic puzzle and ensures fairness in the allocation of mining rewards[38, 39]. (ii) Miners can be selected as the next block creators only when they actually create and submit the block to the network. This property says that the random selection of the next block creator and the creation of the next block occur simultaneously.

Proof of Stake (PoS) or virtual mining protocols [14] constitute alternative selection mechanisms that aim to retain PoW’s benefits while improving on its weaknesses [11, 15]. While different PoS protocols propose different schemes[29, 26, 12, 40, 17, 31], in general, the block proposal mechanism is the following: blocks are created by staking nodes, also called validators[32, 41], who are granted the right to participate in the block creation process by locking capital in protocol currency, called stake. Subsequently, a pseudo-random mechanism selects nodes proportionally to their stake to form committees that will decide on the validity of a block proposed by a selected node, called block proposer or leader. At the core of the consensus mechanism, the selected validators cast approval or disapproval votes on the proposed block. If an enhanced majority of approval votes, usually of the committee size [33], is reached, then the proposed block is accepted and appended to the blockchain.

However, maliciously or accidentally abstaining validators can cause consensus failures and stall the blockchain111Malicious absention refers to non-voting or incorrect voting to attack the protocol, whereas accidental abstention refers to a variety of reasons, such as dropping offline, experiencing network latency, bugs in client updates or being a victim of a censoring/eclipse attack.. The reason is, that unlike Nakamoto consensus [46], PoS protocols decouple the selection of block creator(s) from the actual block creation and hence do not satisfy property (ii) above. Since consensus on the “valid” state of the blockchain relies on the voting behavior of all participating validators, this also implies that the actual rate of blocks that a validator gets to create may differ from the times that she gets selected in a committee. Hence, while the PoS selection mechanism aims to ensure fair allocation of “mining” rewards in line with PoW’s property (i) above, in practice, it may fail to do so. These observations motivate the following question

  • How can we improve the efficiency and robustness of the consensus mechanism, i.e., how can we use information on validators’ past voting patterns to enforce that with overwhelming probability the selected validator committees will reach consensus on the

    “valid” state of the blockchain.

The problem of improving consensus has been treated in the context of fixed-size committee voting by a rich stream of literature[36, 37, 44, 49, 10]. The derived solutions hinge on quantifying voters’ abilities to make correct decisions and apply weighted voting rules in which votes are weighted according to voters’ profiles. Our goal is to apply these results in the setting of PoS protocols. The link is immediate, since, as[10] remarks, the assumptions of their original model imply both decentralized information processing and limited communication. The additional challenges that have to be treated in the blockchain context, concern updating these profiles and protecting against their manipulation by adversaries.

To address this problem, we formulate the proper mathematical framework and develop a model to quantify validators’ voting profiles. The proposed scheme is applied once voting committees have formed and does not modify the underlying PoS selection and reward mechanisms. Each staking node (validator) is assigned a score based on her so-far contribution to protocol execution. When selected to a committee, her vote is weighted relative to her profile and consensus is decided according to a weighted majority rule that maximizes the expected collective rewards [44, 10]. Finally, based on her vote and the overall consensus outcome, her voting profile is revised according to a fully parametrisable multiplicative weights update algorithm [2, 8]. Supported by numerical examples and simulations, our findings demonstrate that weighted voting renders the consensus mechanism more efficient, even if more than of nodes are not properly voting. In this way, the proposed scheme restores fairness without compromising other PoS features. Additionally, since it does not modify the underlying PoS mechanism, it can be tested, implemented and reverted with minimal cost to existing protocol users.

Although weighted voting in distributed systems is known to increase efficiency, incentive compatibility [4, 6], and network reliability [7], it also raises additional risks [48, 3, 51]. Similar to proof of reputation systems [50], weighted voting deviates from the principle one node – one vote and hence, is vulnerable to manipulation by adversaries. We raise issues that pertain to weighted voting such as loss of anonymity & centralisation and discuss their relevance to protocol design and implementation. Weighted voting becomes particularly relevant in less anonymous [30], private or permissioned blockchains [1, 45, 47], in delegated PoS protocols [27, 34] and in PoS protocols with low targeted number of staking pools[16].

I-a Outline

In Section II, we abstract the PoS consensus mechanism as a voting game. In Section III, we design the improved voting scheme and illustrate our findings with numerical examples and simulations. We conclude with a discussion about limitations and implementation issues in Section IV and summarise our findings in Section V.

Ii The Model

Our terminology is based on the Ethereum 2.0 PoS protocol specification, [17]. Yet, our model remains as general as possible in an effort to capture similar voting mechanisms implemented by related PoS platforms222Claiming that all PoS protocols fit under this model would be oversimplifying and wrong. Yet, most PoS protocols that we are aware of involve voting mechanisms and hence, may benefit – to a larger or lesser extent – from the present proposal. An incomplete list includes [29, 12, 26, 40, 31]. For more extensive details of PoS protocols, we refer to [15, 9, 21, 19]..



Time is divided into time slots of fixed duration . Each time slot is dedicated to the proposal and creation of a new block . Time slot is the time of creation of the genesis block .


The main actors in the block proposal and creation mechanism are the staking nodes, also called validators, denoted by , where is the set of all validators. will denote the set of blocks for which validator is aware of at time .


The deposit or stake is the amount of the underlying cryptocurrency that a potential validator locks as Proof of Stake (PoS) to participate in the block creation process. Such deposits may change over time. Accordingly, let denote the stake of validator and the total stake at time slot . If , then validator is called active at time slot . Validators who have withdrawn from or who have not entered it yet, can be thought of as validators with stake . Thus, although the set of validators is dynamic, we may write instead of to denote the set of validators at any time ,

Block proposer & committees:

To create blocks and extend the blockchain, active validators are selected proportionally to their stake by a pseudo-random mechanism which assigns to each time slot a leader or block proposer and a fixed-sized committee of validators333The mechanics of the pseudo-random mechanism vary between different protocols. Here, we are not interested in risks associated with manipulating this mechanism and focus on the mechanics of the voting process once a random committee has been formed.. The block proposer is assigned the task to propose a block to the committee. In turn, the committee votes on whether the proposed block should be appended to the blockchain or not. This process constitutes the core of the consensus mechanism and will be the focus of the present paper.

Validators’ strategies:

The set of strategies of a validator who has been selected in a committee will be denoted by , where stands for rejecting and for approving the proposed block. In particular, also corresponds to not casting a vote, either deliberately or accidentally. Accordingly, let

denote the indicator random variable

We will write to denote the decision or action profile of the committee at time .

Decision rule:

A decision rule , also called social choice function or aggregation of preferences rule, is a function that receives as input the action profile and outputs a decision in , where and stand for dissaproval and approval of the proposed block, respectively. We will focus on (simple or enhanced) majority rules defined by


If at least of the selected validators approve the proposed block, then this block is appended to the blockchain. Otherwise, the time slot remains empty and the mechanism progresses to the next time slot.

If block proposers follow the protocol and do not behave maliciously, then all proposed blocks are valid. Moreover, if the network is not partitioned and network latency is insignificant (lower than the time slot duration during which votes are expected to appear), then there is no controversy about which blocks are valid, since all validators view essentially the same blockchain (state), i.e. for all . Under these conditions, the required majority should be reached and valid blocks should be regularly approved and appended [26, 40]. However, in practice, two main reasons may lead to failures on the consensus mechanism

  • [leftmargin=*]

  • adversarial behavior: a malicious node may abstain from voting or censor other validators’ votes to block the required majority and stall the block creation process.

  • accidental behavior: validators may drop offline accidentally or due to negligence, they may experience bugs on client updates, bad network connectivity, their votes may not propagate through the network in the expected time slot or they may be victim themselves of a censoring/eclipse attack.

Our goal is to study how existing results on optimizing aggregation of preferences in committees, in particular [36, 44, 10] can be applied to the PoS blockchain setting and improve the underlying consensus mechanism. The application of these results will be immediate once we have defined the proper framework.

Iii An Improved Voting Rule

To optimize the consensus process from an aggregative perspective, we quantify the collective benefits and losses (payoffs) from correct and wrong decisions respectively. This is done in Table I.

Proposed Block
Valid (1) Invalid (-1)
Committee Approve 1
TABLE I: Collective welfare from consensus outcome.

The benefit from making a correct decision, i.e., approving a valid block or rejecting an invalid block, is scaled to . Here, denotes an invalid and a valid block , cf. Section IV. If a valid block is rejected, then a loss of is incurred which corresponds to the waste of computational resources and the failure of the system to process pending transactions. On the other hand, if validators vote for an invalid block, then represents the losses from validating a conflicting history444This may include approval votes for a block that a malicious node is trying to create in order to double-spend or perform some other kind of attack. It may also involve votes that get wasted on blocks that will be subsequently reverted or abandonded.. Determining the exact values of and is a matter of protocol parametrisation. Finally, let

denote the prior probability that a proposed block is

invalid, e.g., blocks that an adversarial is trying to create.

Given the above, we seek to maximize the expected collective welfare at time slot . depends on the probabilities of accepting a valid block and of rejecting an invalid block under the decision rule ,

and , respectively. Using this notation,

To estimate

and , and hence, to maximize , we need to reason about the decision rule and particularly, about the distribution of the decision variables . Fortunately, this can be done by retrieving existing information about validators’ past votes that have been stored as messages on the blockchain. This is captured by the notion of validators’ voting profiles.


Voting profiles:

Each validator is assigned a score that corresponds to their voting profile at the start of time slot . The value can be thought of as validator ’s decision ability or probability that will vote correctly, i.e.,

for . In its simplest form, is equal to the fraction of validators ’s correct votes to the number of slots in that was selected in a committee. This expression is only given to provide some intuition and in what follows, we will examine a different scheme that depends on the collective welfare of the consensus outcome, Table I.

Initializing & suspending profiles:

We will set a newly entering validator ’s voting profile at and will require that , for any , where denotes an initial grace period. If , for some , then validator will be suspended from . The reasoning behind these choices is detailed in Section IV.

Updating scheme:

In general, an updating scheme is given by a function which revises validator ’s voting profile after time slot based on ’s prior voting profile , the correctness of her voting decision and the current state , i.e.,

for . The current state may include all relevant information, such as the collective welfare parameters, cf. Table I, the validity of the proposed block and the consensus outcome. If a validator has not be selected for slot , then simply . A concrete updating scheme that fits in this description is developed in Section III.

We now return to the problem of maximizing the collective welfare . For a selected validator committee at time slot

, we may condition on the vector of validators’ voting profiles

and write the probability of approving a correct block with the decision rule as

and similarly for . The expression for is derived as follows: The summation ranges over all action profiles for which the decision rule approves the proposed block. The double product inside the parenthesis is precisely the likelihood of each of these profiles based on the assumption that validators’ decisions are independent. Specifically, the first product ranges over all validators who vote correctly, i.e., , and multiplies each one’s probability of a correct vote, i.e., , and the second ranges over the remaining validators who vote incorrectly, i.e., , and multiplies each one’s probability of voting incorrectly, i.e., . Given these expressions, the problem of maximizing can now be studied as an instant of the committee-voting models in [10] and [36, 44].

Example 1 ([44]).

Consider a committee of validators with voting profiles, i.e., empirical probabilities of voting correctly, , as in [44]. In the unweighted case, or equivalently in the case in which all votes are weighted equally, and under the -majority decision rule that is commonly used in PoS protocols, the probability of reaching consensus on the correct block is equal to the probability that at least out of the validators vote correctly. This is

which is lower even than the lowest voting profile of . A naive improvement would be to only consider the vote of the validator with the highest voting profile, i.e., of either the first or the second validator. This would increase the probability of correct voting to , however at a toll on decentralisation.

In the naive improvement of the previous example, the vote of the best validator received a weight of and the vote of all others a weight of . This raises the question of whether we can assign non-trivial weights (scale factors) to all validators and still improve the probability of a correct decision. The answer is affirmative and hinges on the notions of weighted voting and weighted majority rules.


Weighted majority rule:

For a set of validators, let denote a vector of non-negative weights or scaling factors, with . The weighted majority rule, , or simply , is defined as


for . If all votes are equally weighted, i.e., if for all , then (2) reduces to (1).

Using this notation, our goal is to determine the weights and the weighted majority rule – or equivalently the quota – that optimize the collective welfare given the selected committee of validators at time slot , i.e.,


This is the statement of the following Theorem which is due to [10] and in special instances due to [36, 44].

Theorem 2 (Optimal Weighted Voting Scheme,[10]).

Consider a committee of validators with voting profiles that have been selected to vote on the proposed block in time slot . Then, given and the collective welfare parameters in Table I, the decision rule that maximizes the collective welfare, cf. (3), is given by the weighted majority rule , with quota

and individual weights
Remark 3.

According to Theorem 2, the optimal quota (4) depends on the validators’ profiles and hence, it may vary between different time slots . Also, it may vary according to the values of the parameters . For instance, the selection neutralizes the bias due to assumptions on the distribution of valid versus invalid blocks whereas the selection neutralizes the bias due to differences in perceived network costs/rewards. In this way, Theorem 2 maximises the collective welfare – or equivalently, the probability of consensus on the correct decision – by an easily adaptable and dynamic decision rule.

Yet, in blockchain applications, it may be desirable to enforce certain restrictions, as for example that the required weighted majority will be no less than of the total weights or that each individual weight will be no less than some threshold value. As [44, p.332] explains, even in such cases of additional restrictions and/or perturbed assumptions, selecting weights that are proportional (or equal) to the optimal ones (5) will improve the probability of a correct outcome compared to unweighted decision making.

Example 1 (Continued).

Assume for simplicity that and that . In this case, the optimal rule is simple weighted majority, i.e., , or by substituting in (2), if (dependence on is omitted to simplify the notation). Using (5) and normalizing the weights to sum up to , we obtain . With these choices, the probability of approving a valid block is approximately as shown in Table II.

Profiles Weights Decision profiles , with .
0.9 0.392 1 1 1 1 -1 -1 -1
0.9 0.392 1 -1 -1 -1 1 1 1
0.6 0.072 -1,1 1 1 -1,1 1 1 -1,1
0.6 0.072 -1,1 1 -1,1 1 1 -1,1 1
0.6 0.072 -1,1 -1,1 1 1 -1,1 1 1

The weighting has resulted in a voting rule which approves a block if the two high-profile (0.9) validators agree on its validity (first column of decision profiles). The votes of the remaining validators come into play only if these two disagree. In this case, it suffices that a majority ( out of ) of the remaining validators approve the block (remaining columns of decision profiles). The probabilities of decision profiles with sum up to approximately as claimed

The weights yield the same result and are in that sense, equivalent to the optimal ones. In fact, there may be several other optimal choices. As mentioned above, if we impose additional restrictions such as a de facto -weighted majority, the weights given by (5) may not be optimal anymore. However, as [44] remarks, they will still yield an improved probability compared to the unscaled case. In this example, a similar calculation as in Table II shows that the probability of reaching the -majority is with the weights and approximately with the weights.

Iii-a Multiplicative Weights Update Algorithm

We now turn to one of the main challenges of implementing the voting profile scheme in the dynamic blockchain setting, which is the update of voting profiles after every time slot.

1:procedure PoS Selection()
2:     return
3:     return (proposed block)
4:procedure Collect votes()
5:     for  do
6:         if  then
7:              vote
8:         else
9:              vote               
10:procedure Weighted Voting()
11:     for  do
13:         sum sum vote      
15:     if sum &  then
16:         append.block
18:procedure PoS Rewards()
Algorithm 1 Weighted Voting in Committees

The updating scheme may considerably vary depending on the desired result: [50] propose a reputation system in which reputation increases according to a sigmoid function when nodes vote correctly and decreases sharply (to ) after a single violation. While this approach adheres to intuition and comes with certain merits, practical applications may call for more flexibility in the updates. To develop a parameterizable scheme, we utilize the approach of [2] who generalize the standard multiplicative weights update (MWU) algorithm to a non-binary setting in which experts’ scores are revised according to the impact of their decision on the social welfare.

Using Table I, the corresponding MWU algorithm for the present application is given in Table III.

Proposed Block
Valid (1) Invalid (-1)
Committee Approve
TABLE III: Multiplicative Weights Updates.

Here, is a (small) number subject to the exact protocol parametrisation. Apart from the efficiency properties of the MWU algorithm that are well known, see [2, 8] and references therein, this scheme can leverage the prevailing network conditions and adjust the updates accordingly. This can be realized by replacing and/or with sequences of updating parameters, .

Algorithm 1 summarises the weighted voting procedure. Validators are selected and rewarded according to the underlying PoS protocol (lines 1 and 18). The weighted voting procedure555The function that determines the optimal quota is given in a general form (line 14) to account for implementations with a rule different from the one proposed in (4), as e.g., a constant -majority rule. is applied once the committee has been formed (lines 10 to 17) without modifying the rest of the protocol. In this way, it contributes towards a more efficient and fair consensus mechanism while remaining decoupled from the PoS selection mechanism. This results in a two-layered scheme that on the one hand improves the efficiency of the consensus mechanism and restores the fairness property of the PoS protocol and on the other hand can be implemented and reverted with minimal cost to the users. The proposed scheme for updating validators’ voting profiles is given for completeness in Algorithm 2.

1:procedure MWUpdate()
2:     initialize:
3:     while  do
4:         if  &  then
6:         else if  then
7:              if  then
9:              else if  then
11:              else
Algorithm 2 Validators’ Voting Profiles

The and expressions (lines 8,10,12) ensure that the profiles remain in .

Iii-B Numerical results

Figure 1 provides an instantiation of the proposed weighted voting scheme and MWU algorithm. In the illustrated scenario, an adversary is blocking of the votes. At the start of the attack, all validators have a voting profile . We examine two choices of the updating parameter (red) and (blue). In both cases, and to capture the higher costs from approvals of invalid blocks. The depicted curves indicate that the weighted approval votes (vertical axis) rise above the majority threshold666While the optimal quota, cf. (4), remains slightly above , we consider the -majority rule which is currently implemented in PoS protocols. for both cases. The pace is different and depends on the selection of . The knicks in both lines correspond to the point in which the scores of voting validators numerically reach . After this point, the majority of the voting validators increases at a very slow pace which is a desirable property that allows for a more smooth recovery in case that the abstaining resume voting.

Fig. 1: Time slots to resuming consensus on valid blocks with non-voting nodes under mild (red line) and aggressive (blue line) updating parameter . In both cases, .

As a comparison, Figure 2 illustrates the process of resuming approval of blocks in the same scenario but with an adversary controlling of the stake (left panel) and of the stake (right panel). The results indicate a very similar recovery pattern, cf. Figure 1, independenlty of the initial stake of the non-voting validators.

Fig. 2: Time slots to resuming consensus on valid blocks with (left panel) and (right panel) non-voting nodes under mild (red line) and aggressive (blue line) updating parameter . In both cases, .

The evolution of a validator’s voting profile is illustrated in Figure 3. In the depicted scenario, the validator’s initial profile is . She votes correctly of the time, but drops of the time off-line, and votes on invalid blocks another of the time. The exact formula for updating her profile is

where is the value calculated by Table III. This formula ensures that remains in . Again, we examine two cases for different values of the update parameter, (lefta panel) and (right panel).

Fig. 3: Evolution of a validator’s voting profile who periodically drops offline and periodically votes on an invalid block for different values of parameter . In both panels, the validator’s initial score is , and .

While the patterns differ, in both depicted panels the voting profile falls due to the regular incorrect votes. We remark, that lower values of would result in upwards sloping curves (not depicted here) implying that a validator could regularly vote incorrectly and still improve her voting profile. Similarly, higher values of would allow validators to quickly recover their profiles after pitfalls which is an undesirable property. The depicted patterns in the evolution of the voting profile are robust in the choice of the initial score and the value of .

Finally, Figure 4 extends the above scenarios to a period in which the validator resumes proper voting. Specifically, we assume that the validator votes correctly on every block except of occasional time slots – less than of the time – in which she goes offline. Again, the two panels correspond to different values of .

Fig. 4: Recovery of the validator’s voting profile after resuming proper voting (with only occasional offline-drops) in the scenarios of Figure 3. Recovery exhibits linear pattern for both choices of . It is fast for (aggresive adjustment) and slow for (mild adjustments).

In both cases, the pattern is linear (the knicks correspond to the occasional drops) with a slope that can be adjusted by the choice of . In sum, the provided simulations support the versatility of the proposed scheme, leaving the exact parametrisation (static or dynamic) subject to each protocol’s implementation and scope.

Iv Design & Limitations

The introduction of validators’ voting profiles and the resulting improvement in the consensus mechanism come with a trade-off in terms of security. Since the system becomes reliable on information that can be retrieved from the blockchain – validators’ votes are stored as messages [18] – risks associated with adversarial manipulation of this information are raised. In the current section, we try to address these risks and discuss relevant implementation issues and limitations.

Staking nodes & anonymity

Since nodes become identifiable by their scores, anonymity is reduced or lost which is at odds with the design philosophy of permissionless blockchains. Yet, with blockchain governance yet to be determined, introducing less anonymity may be a desired feature. Recent results point to a relative low desired number of staking nodes

[18] or stake pools [16]. In such schemes, reputation will implicitly or explicitly influence protocol execution. Moreover, stake pools retain anonymity at a user level, i.e., while the pool becomes identifiable by its voting profile, the users remain anonymous. In any case, the introduction of voting profiles and weighted voting seems particularly relevant to permissioned or private blockchains.

Defense against known attacks

Weighted voting improves the resilience of the underlying PoS mechanism against the following known vulnerabilities. First, adversaries who control more than of the total stake wield the power to stall (or delay) the blockchain, see e.g. [26, 40]. To defend against such attacks, current PoS proposals leverage the fact that non-voting nodes can be identified and introduce penalties to reduce their stake [17, 5]. However, these actions are ineffectual against adversaries who can replenish their stake and withstand the penalties. Although pessimistic, this scenario – in which adversaries sustain an attack despite suffering losses on their own stake – gains credence in the presence of potential out-of-protocol profits. Second, PoS consensus mechanisms are vulnerable to entering nodes that aim to attack the protocol by flash or blindsiding attacks[13, 20]. Finally, network issues – latency, bad connectivity – negligence, or even censoring, can reduce the fraction of voting validators below the required majority. The proposed weighted voting scheme provides lines of defense (in an obvious way) against these kinds of attacks or faults while retaining the benefits of the underlying PoS design. In addition, the preserved reliance on PoS for the selection of validators in committees and the allocation of rewards, protects against adversarial nodes that maintain small stake but high voting profile or vice versa.

Valid-invalid blocks & updating scheme

A likely contentious assumption of the present model is that proposed blocks can be indentified as valid or invalid. In practice, different nodes may have different views of the blockchain and hence perceive proposed block differently. Yet, on closer inspection, this assumption can still be supported in the current framework: if a node is honest but has a (completely) different view of the canonical chain due to (say) poor connection to the network, then her votes do not contribute to extending the canonical chain and indeed can be regarded as incorrect. For instance, in Ethereum, which is the base case for this paper, valid–invalid votes are well-defined and identified [42, 41].

Dealing with this issue becomes more relevant in the design of the updating scheme. Clearly, faults that can be identified as deliberate should be treated differently than accidental ones. For instance, a validator who has honestly participated in the protocol for a long period of time and drops offline for a short period of time, should be able to quickly recover her previous voting profile. This motivates updating profiles by two variables and representing short-term and long-term voting respectively. In general, if the idea of weighted voting gains support, then different methods should be tested and analyzed in future research.

Computational overhead

While this issue is not treated in the current study, storing and updating validators’ voting profiles is not expected to add a significant overhead in the protocol. The updating computations are linear in the number of validators in a committee whereas the extra data storage is limited to one additional value per validator. However, similarly to testing different updating schemes (previous point), computational issues should be addressed in future studies.

Entry & threshold voting profiles

The choice of initializing voting profiles at represents an uninformative prior on an entering’s validators voting profile. Subsequently, the requirement that remains in for all , where denotes a potential initial grace period, enforces a more stable protocol execution. While the reason for the upper bound is purely numerical, namely to avoid the instability in if , the suspension of validators with voting profile – or probability of making a correct decision – lower than is more fundamental. [10] provide a detailed probabilistic argument to explain that such voters are harmful to consensus and their votes should not be considered. Moreover, in the specific context of distributed networks, allowing nodes to participate with scores lower than their initial score can trigger Sybil attacks, since it motivates switching to new or creating multiple accounts. Finally, suspending validators in terms of their voting behavior relaxes the need for frequent economic penalties [18]. This makes the PoS ecosystem more secure and appealing to investors who would otherwise be concerned of suffering losses due to accidental misbehavior, e.g., dropping off-line or being censored.

V Summary & Conclusions

Existing PoS protocols select staking nodes proportionally to their stake to form block-creating committees. Yet, they do not guarantee that selected committees will create blocks, since consensus may fail due to accidental or adversarial behavior. Thus, the perceived fairness in the distribution of rewards in proportion to the stake of participating nodes is actually violated. Motivated by this observation, we studied weighted voting as a way to improve the consensus mechanism. We introduced validators’ voting profiles – that quantify the probability that a validator will cast a correct vote based on her so far contribution to the protocol – and defined the proper mathematical framework to apply the results of [10] on optimal decision rules in committee voting. Using the approach of [2], we designed a multiplicative weights algorithm to update individual validator’s profiles according to their voting behavior, the consensus outcome and collective blockchain welfare. The result is a two-layered scheme in which selection of nodes and allocation of rewards are performed by the underlying PoS mechanism whereas blocks are decided by a weighted majority voting rule. This scheme improves consensus within selected committees by scaling votes according to validators’ profiles without interfering with the PoS execution. Hence, it can be tested, implemented and reverted with minimal cost to existing users. On the negative side, the introduction of a profiling scheme in a distributed network raises new risks associated with manipulation of the relevant information. We discussed such risks along with actions that should be considered in the design of future PoS protocols.


  • [1] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich, S. Muralidharan, C. Murthy, B. Nguyen, M. Sethi, G. Singh, K. Smith, A. Sorniotti, C. Stathakopoulou, M. Vukolić, S. W. Cocco, and J. Yellick. Hyperledger fabric: A distributed operating system for permissioned blockchains. In Proceedings of the Thirteenth EuroSys Conference, EuroSys ’18, pages 30:1–30:15, New York, NY, USA, 2018. ACM.
  • [2] S. Arora, E. Hazan, and S. Kale. The Multiplicative Weights Update Method: a Meta-Algorithm and Applications. Theory of Computing, 8(6):121–164, 2012.
  • [3] H. Aziz and M. Paterson. False Name Manipulations in Weighted Voting Games: Splitting, Merging and Annexation. In Proceedings of The 8th International Conference on Autonomous Agents and Multiagent Systems - Volume 1, AAMAS ’09, pages 409–416, Richland, SC, 2009. International Foundation for Autonomous Agents and Multiagent Systems.
  • [4] H. Aziz, M. Paterson, and D. Leech. Efficient Algorithm for Designing Weighted Voting Games. In 2007 IEEE International Multitopic Conference, pages 1–6, Dec 2007.
  • [5] S. Azouvi, P. McCorry, and S. Meiklejohn. Betting on Blockchain Consensus with Fantomette. ArXiv e-prints, 2018.
  • [6] Y. Azrieli and S. Kim. Pareto Efficiency and Weighted Majority Rules. International Economic Review, 55(4):1067–1088, 2014.
  • [7] Y. Bachrach, J. Rosenschein, and E. Porat. Power and Stability in Connectivity Games. In Proceedings of the 7th International Joint Conference on Autonomous Agents and Multiagent Systems - Volume 2, AAMAS ’08, pages 999–1006, Richland, SC, 2008. International Foundation for Autonomous Agents and Multiagent Systems.
  • [8] J. P. Bailey and G. Piliouras. Multiplicative weights update in zero-sum games. In Proceedings of the 2018 ACM Conference on Economics and Computation, EC ’18, pages 321–338, New York, NY, USA, 2018. ACM.
  • [9] S. Bano, A. Sonnino, M. Al-Bassam, S. Azouvi, P. McCorry, S. Meiklejohn, and G. Danezis. Consensus in the age of blockchains. arXiv preprint arXiv:1711.03936, 2017.
  • [10] R. C. Ben-Yashar and S. I. Nitzan. The Optimal Decision Rule for Fixed-Size Committees in Dichotomous Choice Situations: The General Result. International Economic Review, 38(1):175–186, 1997.
  • [11] I. Bentov, A. Gabizon, and A. Mizrahi. Cryptocurrencies without proof of work. In J. Clark, S. Meiklejohn, P. Y. Ryan, D. Wallach, M. Brenner, and K. Rohloff, editors, Financial Cryptography and Data Security, pages 142–157, Berlin, Heidelberg, 2016. Springer Berlin Heidelberg.
  • [12] I. Bentov, R. Pass, and E. Shi. Snow white: Provably secure proofs of stake. Cryptology ePrint Archive, Report 2016/919, 2016. https://eprint.iacr.org/2016/919.
  • [13] J. Bonneau, E. Felten, S. Goldfeder, J. Kroll, and A. Narayanan. Why buy when you can rent ? Bribery attacks on Bitcoin consensus, 2015.
  • [14] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten. SoK: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies. In 2015 IEEE Symposium on Security and Privacy, pages 104–121, 2015.
  • [15] J. Brown-Cohen, A. Narayanan, C.-A. Psomas, and S. M. Weinberg. Formal Barriers to Longest-Chain Proof-of-Stake Protocols. ArXiv e-prints, 2018.
  • [16] L. Brünjes, A. Kiayias, E. Koutsoupias, and A.-P. Stouka. Reward Sharing Schemes for Stake Pools. ArXiv e-prints, page arXiv:1807.11218, July 2018.
  • [17] V. Buterin. Ethereum 2.0 spec – Casper and sharding, 2018. Available [online]. [Accessed: 30-10-2018].
  • [18] V. Buterin and V. Griffith. Casper the Friendly Finality Gadget. ArXiv e-prints, 2017.
  • [19] C. Cachin and M. Vukolic. Blockchain Consensus Protocols in the Wild. CoRR, abs/1707.01873, 2017.
  • [20] V. Chia, P. Hartel, Q. Hum, S. Ma, G. Piliouras, D. Reijsbergen, M. van Staalduinen, and P. Szalachowski. Rethinking blockchain security: Position paper. In Proceedings of IEEE Blockchain 2018, 2018.
  • [21] T. T. A. Dinh, R. Liu, M. Zhang, G. Chen, B. C. Ooi, and J. Wang. Untangling Blockchain: A Data Processing View of Blockchain Systems. IEEE Transactions on Knowledge and Data Engineering, 30(7):1366–1385, 2018.
  • [22] I. Eyal and E. Sirer. Majority is not enough: Bitcoin mining is vulnerable. In N. Christin and R. Safavi-Naini, editors, Financial Cryptography and Data Security, pages 436–454, Berlin, Heidelberg, 2014. Springer Berlin Heidelberg.
  • [23] J. Garay, A. Kiayias, and N. Leonardos. The Bitcoin Backbone Protocol: Analysis and Applications. In E. Oswald and M. Fischlin, editors, Advances in Cryptology - EUROCRYPT 2015, pages 281–310. Springer Berlin Heidelberg, 2015.
  • [24] J. Garay, A. Kiayias, and N. Leonardos. The Bitcoin Backbone Protocol with Chains of Variable Difficulty. In CRYPTO, pages 291–323. Springer, 2017.
  • [25] J. A. Garay, A. Kiayias, N. Leonardos, and G. Panagiotakos. Bootstrapping the Blockchain, with Applications to Consensus and Fast PKI Setup. Cryptology ePrint Archive, Report 2016/991, 2016. https://eprint.iacr.org/2016/991.
  • [26] Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich. Algorand: Scaling Byzantine Agreements for Cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, SOSP ’17, pages 51–68, New York, NY, USA, 2017. ACM.
  • [27] I. Grigg. EOS – An Introduction, 2017. Available [online]. [Accessed: 17-12-2018].
  • [28] A. Kiayias, E. Koutsoupias, M. Kyropoulou, and Y. Tselekounis. Blockchain mining games. In Proceedings of the 2016 ACM Conference on Economics and Computation, EC ’16, pages 365–382, 2016.
  • [29] A. Kiayias, A. Russell, B. David, and R. Oliynykov. ”ouroboros: A provably secure proof-of-stake blockchain protocol”. In J. Katz and H. Shacham, editors, Advances in Cryptology – CRYPTO 2017, pages 357–388. Springer International Publishing, 2017.
  • [30] P. Koshy, D. Koshy, and P. McDaniel. An Analysis of Anonymity in Bitcoin Using P2P Network Traffic. In N. Christin and R. Safavi-Naini, editors, Financial Cryptography and Data Security, pages 469–485. Springer Berlin Heidelberg, 2014.
  • [31] J. Kwon. Tendermint: Consensus without mining, 2014. Available [online]. [Accessed: 17-12-2018].
  • [32] J. Kwon. Tendermint Core, 2014. Available [online]. [Accessed: 17-12-2018].
  • [33] L. Lamport, R. Shostak, and M. Pease. The Byzantine Generals Problem. ACM Trans. Program. Lang. Syst., 4(3):382–401, July 1982.
  • [34] Lisk. Lisk’s Consensus Algorithm, 2018. Available [online]. [Accessed: 17-12-2018].
  • [35] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. Available: [online]. [Accessed: 14-11-2018].
  • [36] S. Nitzan and J. Paroush. Optimal Decision Rules in Uncertain Dichotomous Choice Situations. International Economic Review, 23(2):289–297, 1982.
  • [37] S. Nitzan and J. Paroush. Are Qualified Majority Rules Special? Public Choice, 42(3):257–272, 1984.
  • [38] R. Pass, L. Seeman, and A. Shelat. ”analysis of the blockchain protocol in asynchronous networks”. In J.-S. Coron and J.-B. Nielsen, editors, Advances in Cryptology – EUROCRYPT 2017, pages 643–673. Springer International Publishing, 2017.
  • [39] R. Pass and E. Shi. Fruitchains: A fair blockchain. In Proceedings of the ACM Symposium on Principles of Distributed Computing, PODC ’17, pages 315–324, New York, NY, USA, 2017. ACM.
  • [40] R. Pass and E. Shi. ”thunderella: Blockchains with optimistic instant confirmation”. In J.-B. Nielsen and V. Rijmen, editors, Advances in Cryptology – EUROCRYPT 2018, pages 3–33, 2018.
  • [41] D. Ryan. Validator Implementation Guide, 2018. Available [online]. [Accessed: 17-12-2018].
  • [42] D. Ryan and C.-C. Liang. Ethereum improvement proposal 1011. Available: [online]. [Accessed: 3-9-2018].
  • [43] A. Sapirshtein, Y. Sompolinsky, and A. Zohar. Optimal selfish mining strategies in bitcoin. In J. Grossklags and B. Preneel, editors, Financial Cryptography and Data Security, pages 515–532, Berlin, Heidelberg, 2017. Springer Berlin Heidelberg.
  • [44] L. Shapley and B. Grofman. Optimizing group judgmental accuracy in the presence of interdependencies. Public Choice, 43(3):329–343, 1984.
  • [45] C. Stathakopoulou. On Scalability and Performance of Permissioned Blockchain Systems. 2018.
  • [46] N. Stifter, A. Judmayer, P. Schindler, A. Zamyatin, and E. R. Weippl. Agreement with Satoshi – On the Formalization of Nakamoto Consensus. IACR Cryptology ePrint Archive, 2018:400, 2018.
  • [47] G. Vizier and V. Gramoli. ComChain: Bridging the Gap Between Public and Consortium Blockchains. In Proceedings of the IEEE International Conference on Blockchain (Blockchain’18), Jul 2018.
  • [48] Y. Bachrach and E. Elkind. Divide and conquer: false-name manipulations in weighted voting games. In AAMAS, 2008.
  • [49] P. Young. Optimal Voting Rules. Journal of Economic Perspectives, 9(1):51–64, March 1995.
  • [50] J. Yu, D. Kozhaya, J. Decouchant, and P. Verissimo. RepuCoin: Your Reputation is Your Power. Cryptology ePrint Archive, Report 2018/239, 2018. https://eprint.iacr.org/2018/239.
  • [51] M. Zuckerman, P. Faliszewski, Y. Bachrach, and E. Elkind. Manipulating the quota in weighted voting games. Artificial Intelligence, 180–181:1–19, 2012.