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

TL;DR

This paper proposes a weighted voting scheme for Proof of Stake blockchain protocols, enhancing consensus robustness by dynamically adjusting validator influence based on their voting behavior and rewards.

Contribution

It introduces a formal framework for weighted voting in PoS protocols, optimizing collective decision-making and improving fault tolerance.

Findings

Weighted voting increases consensus robustness.

Validators' influence can be optimized via multiplicative weights.

The approach is supported by numerical and analytical analysis.

Abstract

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.

Tables

Table 1. TABLE I: Collective welfare from consensus outcome.

		Proposed Block $B_t$
		Valid (1)	Invalid (-1)
Committee	Approve	1	$-{\ell }_a$
	Reject	$-{\ell }_r$	$1$

Table 2. TABLE II: Winning profiles under the optimal decision scheme.

Profiles	Weights	Decision profiles $𝐱$, with $f_{\overline{q}}\left(𝐱\right)=1$.
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
${\sum }_{i=1}^5{w}_i{x}_i$		$>0$	$>0$	$>0$	$>0$	$>0$	$>0$	$>0$

Table 3. TABLE III: Multiplicative Weights Updates.

		Proposed Block $B_t$
		Valid (1)	Invalid (-1)
Committee	Approve	$p_{i,t}\left(1+\delta \right)$	$p_{i,t}{\left(1-\delta \right)}^{{\ell }_a}$
	Reject	$p_{i,t}{\left(1-\delta \right)}^{{\ell }_r}$	$p_{i,t}\left(1+\delta \right)$

Equations

$$X_{i,t}=\{\begin{array}{ll}1,& \text{if validator i voted on the approval of the proposed block Bt in time slot t}\\ -1,& \text{otherwise}\end{array}$$

$$f_q\left({\mathbf{x}}_t\right):=\{\begin{array}{ll}1,& \text{if }{\sum }_{i=1}^n{x}_{i,t}\ge \left(2q-1\right)n,\\ -1,& \text{otherwise}\end{array}$$

$${\pi }_1\left(f_q\right):=P\left(f_q\left({\mathbf{X}}_t\right)=1\mid B_t=1\right)$$

$$E_t\left(f_q\right)=\left(1-\alpha \right)\left(1+{\ell }_r\right){\pi }_1\left(f_q\right)+\alpha \left(1+{\ell }_a\right){\pi }_{-1}\left(f_q\right)$$

$$p_{i,t}:=P\left(X_{i,t}=1\mid B_t=1\right)=P\left(X_{i,t}=-1\mid B_t=-1\right)$$

$$p_{i,t+1}=h\left(p_{i,t},x_{i,t},{\mathcal{B}}_t\right)$$

$$\begin{gathered} {\pi }_1\left(f_q\mid {\mathbf{p}}_t\right)=\sum _{{\mathbf{x}}_t:f_q\left({\mathbf{x}}_t\right)=1}\left(\prod _{i: \\ {x}_{i,t}=1}{p}_{i,t}\prod _{j:x_{j,t}=-1}\left(1-p_{j,t}\right)\right) \end{gathered}$$

$$0.9^{2}0.6^3+2\cdot 0.6^3\left(0.9\right)\left(0.1\right)+3\cdot 0.9^{2}0.6^2\left(0.4\right)\approx 0.56$$

$$f_q\left({\mathbf{x}}_t\right):=\{\begin{array}{ll}1,& \text{if }{\sum }_{i=1}^n{w}_{i,t}{x}_{i,t}\ge \left(2q-1\right)w_t,\\ -1,& \text{otherwise}\end{array}$$

$$\underset{q,{\mathbf{w}}_t}{\max }\left\{E_t\left(f_q,w_t\right)\right\}$$

$${\overline{q}}_t$$

$$w_{i,t}$$

$$E_t\left(f_q\right)$$

$$=\left(1-\alpha \right)\left(1+{\ell }_r\right)\sum _{{\mathbf{x}}_t:f_q\left({\mathbf{x}}_t\right)=1}\left(\prod _{i:x_{i,t}=1}{p}_{i,t}\prod _{j:x_{j,t}=-1}\left(1-p_{j,t}\right)\right)+\alpha \left(1+{\ell }_a\right)\sum _{{\mathbf{x}}_t:f_q\left({\mathbf{x}}_t\right)=-1}\left(\prod _{i:x_{i,t}=-1}{p}_{i,t}\prod _{j:x_{j,t}=1}\left(1-p_{j,t}\right)\right)$$

$$=\sum _{{\mathbf{x}}_t:f_q\left({\mathbf{x}}_t\right)=1}\left(\left(1-\alpha \right)\left(1+{\ell }_r\right)\prod _{i:x_{i,t}=1}{p}_{i,t}\prod _{j:x_{j,t}=-1}\left(1-p_{j,t}\right)\right)+\sum _{{\mathbf{x}}_t:f_q\left({\mathbf{x}}_t\right)=-1}\left(\alpha \left(1+{\ell }_a\right)\prod _{i:x_{i,t}=-1}{p}_{i,t}\prod _{j:x_{j,t}=1}\left(1-p_{j,t}\right)\right)$$

$$\left(1-\alpha \right)\left(1+{\ell }_r\right)\prod _{i:x_{i,t}=1}{p}_{i,t}\prod _{j:x_{j,t}=-1}\left(1-p_{j,t}\right)>\alpha \left(1+{\ell }_a\right)\prod _{i:x_{i,t}=-1}{p}_{i,t}\prod _{j:x_{j,t}=1}\left(1-p_{j,t}\right)$$

$$\frac{1-\alpha }{\alpha }\cdot \frac{1+{\ell }_r}{1+{\ell }_a}\prod _{i:x_{i,t}=1}\frac{p_{i,t}}{\left(1-p_{i,t}\right)}>\prod _{j:x_{j,t}=-1}\frac{p_{i,t}}{\left(1-p_{j,t}\right)}$$

$$\ln \left(\frac{1-\alpha }{\alpha }\right)+\ln \left(\frac{1+{\ell }_r}{1+{\ell }_a}\right)+\sum _{i:x_{i,t}=1}\ln \left(\frac{p_{i,t}}{1-p_{i,t}}\right)>\sum _{j:x_{j,t}=-1}\ln \left(\frac{p_{j,t}}{1-p_{j,t}}\right)$$

$$y_i=\{\begin{array}{ll}1,& \text{if }{x}_i=1,\\ 0,& \text{if }{x}_i=-1\end{array}$$

$$z_i=\{\begin{array}{ll}1,& \text{if }{x}_i=-1,\\ 0,& \text{if }{x}_i=1\end{array}$$

$$\ln \left(\frac{1-\alpha }{\alpha }\right)+\ln \left(\frac{1+{\ell }_r}{1+{\ell }_a}\right)+\sum _{i=1}^n\left[\ln \left(\frac{p_{i,t}}{1-p_{i,t}}\right)y_i-\ln \left(\frac{p_{i,t}}{1-p_{i,t}}\right)z_i\right]>0$$

$$\sum _{i=1}^n\ln \left(\frac{p_{i,t}}{1-p_{i,t}}\right)x_i>-\ln \left(\frac{1-\alpha }{\alpha }\right)-\ln \left(\frac{1+{\ell }_r}{1+{\ell }_a}\right)$$

$$\left(2{\overline{q}}_t-1\right)w_t=-\ln \left(\frac{1-\alpha }{\alpha }\right)-\ln \left(\frac{1+{\ell }_r}{1+{\ell }_a}\right)$$

$$\sum _{i=1}^n{w}_{i,t}^{\prime }\left(2y_i-1\right)\ge 2{\overline{q}}_t-1$$

$$2\sum _{i=1}^n{w}_{i,t}^{\prime }{y}_i-\sum _{i=1}^n{w}_{i,t}^{\prime }\ge 2{\overline{q}}_t-1$$

$$\sum _{i=1}^n{w}_{i,t}^{\prime }{y}_i\ge {\overline{q}}_t$$

$$0.9^2+\left(\genfrac{}{}{0ex}{}{2}{1}\right)0.9\cdot 0.1\left(\left(\genfrac{}{}{0ex}{}{3}{3}\right)0.6^3+\left(\genfrac{}{}{0ex}{}{3}{2}\right)0.6^2\cdot 0.4\right)\approx 0.927$$

$$q\ge c_1\left(1-c_2{q}_1\right)$$

$$p_T$$

$$q\ln \left(1+\delta \right)+\left({\ell }_r{q}_1+{\ell }_a\left(1-q-q_1\right)\right)\ln \left(1-\delta \right)>0$$

$$q\ge \frac{1}{1-\frac{\ln \left(1+\delta \right)}{{\ell }_a\ln \left(1-\delta \right)}}\cdot \left(1-q_1\left(1-{\ell }_r/{\ell }_a\right)\right)$$

$$c_1={\ell }_a\cdot {\left({\ell }_a-\frac{\ln \left(1+\delta \right)}{\ln \left(1-\delta \right)}\right)}^{-1}$$

Full text

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.

I Introduction

In the Nakamoto consensus protocol [44] that underpins the popular Bitcoin cryptocurrency, a single miner claims the right to append the next block to the blockchain by a demonstrating so-called Proof of Work (PoW), i.e., the solution to a moderately hard cryptographic puzzle. The strengths and vulnerabilities of this mechanism are well understood, see [27, 29, 28] and [26, 32, 54]. Two fundamental properties satisfied by PoW selection are the following: (i) Miners holding $p\%$ of computational power will create on average $p\%$ 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[48, 49]. (ii) Miners can be selected as the next block creators only when they actually create and submit the block to the network. This property asserts 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 [16] constitute alternative selection mechanisms that aim to retain PoW’s benefits while improving on its weaknesses [13, 17]. While different PoS protocols propose different schemes[33, 30, 14, 50, 19, 36], in general, the block proposal mechanism is the following: blocks are created by staking nodes, also called validators[37, 52], 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 $2/3$ of the committee size [38], 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 [59], 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 they get 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[45, 46, 56, 61, 12]. The derived solutions depend 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 remarked in [12], 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 the updating of these profiles and protection 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 their so-far contribution to protocol execution. When selected for a committee, their vote is weighted relative to their profile and consensus is decided according to a weighted majority rule that maximizes the expected collective rewards [56, 12]. Finally, based on their vote and the overall consensus outcome, their voting profile is revised according to a fully parametrizable multiplicative weights update algorithm [2, 9]. Supported by numerical examples and simulations, our findings demonstrate that weighted voting renders the consensus mechanism more efficient, even if more than $1/3$ 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.

We raise issues that pertain to weighted voting such as loss of anonymity & centralization and discuss their relevance to protocol design and implementation.

I-A Related Work

Although weighted voting in distributed systems is known to increase efficiency, incentive compatibility [4, 6], and network reliability [8], it also raises additional risks [7, 3, 63]. Similar to proof of reputation systems [62], weighted voting deviates from the principle one node – one vote and hence, is vulnerable to manipulation by adversaries. Weighted voting becomes particularly relevant in less anonymous [35], private or permissioned blockchains [1, 58, 60], in delegated PoS protocols [31, 42] and in PoS protocols with low targeted number of staking pools[18]. However, under rather general assumptions it can also be relevant for permissionless Proof of Stake or hybrid Proof of Work and Proof of Stake systems [19, 33]. We provide such a use case in Section V-A.

A profiling system reduces or eliminates the anonymity of staking nodes which is at odds with the design philosophy of permissionless blockchains [41, 39]. However, with blockchain governance yet to be determined, introducing less anonymity may be a desired feature. Recent results support relatively low desired numbers of staking nodes [20] or stake pools [18]. In such schemes, reputation will implicitly or explicitly influence protocol execution. Moreover, stake pools can retain anonymity at the user level, i.e., while the pool itself 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 blockchains or delegated PoS mechanisms.

More interesting is the implementation of the weighted voting algorithm in conjunction with state of the art consensus schemes such as the delegated Proof of Stake of EOS.IO [31]. Instead of substituting the underlying consensus mechanism, the weighted voting scheme enhances its functionality and operability by providing an additional layer of defense against accidental or adversarial system failures. In fact, in consensus systems that use a limited number of delegates, weighted voting can prove beneficial in accelerating consensus and enhancing their scalability, liveness and safety. This rests on the fact that assigning and updating profiles to the delegates is much easier than in general permissionless blockchains. However, even in the latter case, the expected latency (and overhead) that will be introduced to the system by the profiling system does not exceed nor significantly increases the computational complexity of updating the validators’ stakes.

Finally, claiming that all PoS protocols fit under the stylized model – see Section II – that we use to design the proposed weighted voting scheme would be an oversimplification 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 [33, 14, 30, 50, 36]. For more extensive details of PoS protocols, we refer to [17, 10, 24, 22]. Further comparisons to existing proposals and implementation details are given in Section VI

I-B Outline

In Section II, we abstract the PoS consensus mechanism as a voting game. In Section III, we construct the improved voting scheme and illustrate it with examples. Section IV is devoted to the design of the updating algorithm and the derivation of bounds on the validators’ faulty behavior that can be tolerated with significantly affecting their profiles. The resulting scheme – weighted voting rule and multiplicative weight updating algorithm – are tested and related in potential use cases in Section V. We conclude the paper with a discussion about limitations and implementation issues in Section VI and a summary of our findings in Section VII.

As an extension of a conference paper[40], the present article contributes both technical and application specific materials that make the paper self-contained and enhance the intuition behind the derived results. In addition to a detailed comparison with related work, cf. Section I-A, technical extensions comprise Lemma 1 and its proof, the proof of Theorem 3, Figure 1 and Remark 4. From an application oriented perspective, the present paper elaborates on the design and optimal parametrization of such voting schemes in practice. This is done in Section IV-A, Section V-A and Section V-B in the context of the state of the art PoS proposals and implementations, such as Ethereum with Casper FFG and EOS.IO. The main focus of the analysis is in the mechanics of committee formation and the risk mitigation that is achieved via the proposed scheme for potential investors. In particular, the new content addresses incentives and adversarial behavior in potential use cases and moves forward to explain the steps for the adoption of the proposed scheme in practice.

II The Model

Our terminology is based on the Ethereum 2.0 PoS protocol specification[19]. Yet, our model remains as general as possible in an effort to capture similar voting mechanisms implemented by related PoS platforms.

Time:

Time is divided into time slots $t\in\{0,1,2,\dots\}$ of fixed duration $d$. Each time slot is dedicated to the proposal and creation of a new block $B_{t}$. Time slot $t=0$ is the time of creation of the genesis block $B_{0}$.

Validators:

The main actors in the block proposal and creation mechanism are the staking nodes, also called validators, denoted by $i\in I$, where $I\subseteq\mathbb{N}$ is the set of all validators. $\mathcal{B}_{i,t}$ will denote the set of blocks for which validator $i$ is aware of at time $t\geq 0$.

Stake:

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 $v_{i,t}\geq 0$ denote the stake of validator $i\in I$ and $v_{t}:=\sum_{i\in I}v_{i,t}$ the total stake at time slot $t\in\mathbb{N}$. If $v_{i,t}>0$, then validator $i$ is called active at time slot $t$. Validators who have withdrawn from $I$ or who have not entered it yet, can be thought of as validators with stake $v_{i,t}=0$. Thus, although the set of validators is dynamic, we may write $I$ instead of $I_{t}$ to denote the set of validators at any time $t\geq 0$.

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 $t$ a leader or block proposer and a fixed-sized committee $N_{t}=\{1,2,\dots,n\}$ of validators222The 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 $B_{t}$ 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 $S=\{-1,1\}$, where $-1$ stands for rejecting and $1$ for approving the proposed block. In particular, $-1$ also corresponds to not casting a vote, either deliberately or accidentally. Accordingly, let $X_{i,t}$ denote the indicator random variable

[TABLE]

We will write $\mathbf{X}_{t}:=\left(X_{1,t},X_{2,t},\dots,X_{n,t}\right)$ to denote the random vector of all indicator random variables prior to the validators’ voting decisions and $\mathbf{x}_{t}:=\left(x_{1,t},x_{2,t},\dots,x_{n,t}\right)\in\{-1,1\}^{n}$ to denote the realized decision or action profile of the committee at time $t\geq 0$. Accordingly, we will write $X:=\{-1,1\}^{n}$ to denote the set of all possible decision profiles.

Decision rule:

A decision rule $f:X\to\{-1,1\}$, also called social choice function or aggregation of preferences rule, is a function that receives as input the action profile $\mathbf{x}_{t}$ and outputs a decision in $\{-1,1\}$, where $-1$ and $1$ stand for disapproval and approval of the proposed block, respectively. We will focus on (simple or enhanced) majority rules $f_{q},q\in[0.5,1]$ defined by

[TABLE]

If at least a fraction $q\in[0.5,1]$ 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., $\mathcal{B}_{i,t}:=\mathcal{B}$ for all $i\in I,t\geq 0$. Under these conditions, the required majority should be reached and valid blocks should be regularly approved and appended [30, 50]. However, in practice, two main reasons may lead to failures on the consensus mechanism

• •

adversarial behavior: a malicious node abstains from voting or censors other validators’ votes to block the required majority and stall the block creation process.

• •

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

Our goal is to study how existing results on optimizing aggregation of preferences in committees, in particular the results of [45, 56, 12], 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.

The benefit from making a correct decision, i.e., approving a valid block or rejecting an invalid block, is scaled to $1$. Here, $-1$ denotes an invalid and $1$ a valid block $B_{t}$, cf. Section VI. If a valid block is rejected, then a loss of $\ell_{r}>0$ 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 $\ell_{a}>0$ represents the losses from validating a conflicting history333This 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 $\ell_{r}$ and $\ell_{a}$ is a matter of protocol parametrization. In the present treatment, and without compromising the generality of the results, we will assume that $\ell_{r}\ll\ell_{a}$, i.e., that accepting invalid blocks has greater repercussions for the system, since such blocks typically stem from malicious – and not accidental – behavior. Finally, let $\alpha\in\left(0,1\right)$ 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 $E_{t}$ at time slot $t>0$. $E_{t}$ depends on the probabilities of accepting a valid block and of rejecting an invalid block under the decision rule $f_{q}$,

[TABLE]

and $\pi_{-1}\left(f_{q}\right):=P\left(f_{q}\left(\mathbf{X}_{t}\right)=-1\mid B_{t}=-1\right)$, respectively. Using this notation,

[TABLE]

where we have omitted constant terms. To estimate $\pi_{1}\left(f_{q}\right)$ and $\pi_{-1}\left(f_{q}\right)$, and hence, to maximize $E_{t}$, we need to reason about the decision rule $f_{q}$ and particularly, about the distribution of the decision variables $X_{i,t}$. 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 that we introduce next.

Voting profiles:

Each validator $i\in I$ is assigned a score $p_{i,t}\in[0,1]$ that corresponds to their voting profile at the start of time slot $t$. The value $p_{i,t}$ can be thought of as validator $i$’s decision ability or probability that $i$ will vote correctly, i.e.,

[TABLE]

for $i\in I,t\geq 0$. For instance, in its simplest form, $p_{i,t}$ can be thought of as the fraction of validators $i$’s correct votes to the number of slots in $\{0,1,\dots,t-1\}$ that $i$ was selected in a committee. In what follows, we will examine a more elaborate scheme to define the profiles $p_{i,t}$ that depends on the collective welfare of the consensus outcome, cf. Table I.

Initializing & suspending profiles:

We will set a newly entering validator $i$’s voting profile at $p_{i,0}:=0.5$ and will require that $p_{i,t}\in[0.5,1)$, for any $t\geq g$, where $g\geq 1$ denotes an initial grace period. If $p_{i,t}<0.5$, for some $t\geq g$, then validator $i$ will be suspended from $I$. The reasoning behind these choices is detailed in Section VI.

Updating scheme:

In general, an updating scheme is given by a function $h:[0,1]\times\{-1,1\}\to[0,1]$ which revises validator $i$’s voting profile after time slot $t$ based on $i$’s prior voting profile $p_{i,t}$, the correctness of their voting decision $x_{i,t}$ and the current state $\mathcal{B}_{t}$, i.e.,

[TABLE]

for $t>0$. The current state $\mathcal{B}_{t}$ 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 $i\in I$ has not be selected for slot $t$, then simply $p_{i,t+1}=p_{i,t}$. A concrete updating scheme that fits in this description is developed in Section III.

Given the introduced validators’ voting profiles, we now return to the problem of maximizing the collective welfare $E_{t}$.

Lemma 1**.**

For a selected validator committee $N=\{1,2,\dots,n\}$ at time slot $t$, we may condition on the vector of validators’ voting profiles $\mathbf{p}_{t}=\left(p_{1,t},p_{2,t},\dots,p_{n,t}\right)$ and write the probability $\pi_{1}\left(f_{q}\mid\boldsymbol{\mathbf{p}}_{t}\right)$ of approving a correct block with the decision rule $f_{q}$ as

[TABLE]

and similarly for $\pi_{-1}\left(f_{q}\mid\boldsymbol{\mathbf{p}}_{t}\right)$.

Proof.

This expression for $\pi_{1}\left(f_{q}\mid\boldsymbol{\mathbf{p}}_{t}\right)$ is derived as follows: The summation ranges over all action profiles $\boldsymbol{\mathbf{x}}_{t}$ for which the decision rule $f_{q}$ approves the proposed block, i.e., $f_{q}\left(\boldsymbol{\mathbf{x}}_{t}\right)=1$. The double product inside the parenthesis is precisely the likelihood of each of these profiles given that validators’ decisions are independent. Specifically, the first product ranges over all validators $i\in I$ who vote correctly, i.e., $i:x_{i,t}=1$, and multiplies each one’s probability of a correct vote, i.e., $p_{i,t}$, and the second ranges over the remaining validators $j\in I$ who vote incorrectly, i.e., $j:x_{j,t}=-1$, and multiplies each one’s probability of voting incorrectly, i.e., $(1-p_{j,t})$. ∎

Given these expressions, the problem of maximizing $E_{t}\left(f_{q}\right)$ can now be studied as an instant of the committee-voting models in [12] and [45, 56].

Example 2** (Adjusted from [56]).**

Consider a committee of $5$ validators with voting profiles, i.e., empirical probabilities of voting correctly, $\boldsymbol{\mathbf{p}}=\left(0.9,0.9,0.6,0.6,0.6\right)$, as in [56]. In the unweighted case, or equivalently in the case in which all votes are weighted equally, and under the $2/3$-majority decision rule $f_{2/3}$ that is commonly used in consensus protocols [51, 38], the probability of reaching consensus on the correct block is equal to the probability that at least $4$ out of the $5$ validators vote correctly. This is

[TABLE]

which is lower even than the lowest voting profile of $0.6$. 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 $0.9$, however at a toll on decentralization.

In the naive improvement of the previous example, the vote of the best validator received a weight of $1$ and the vote of all others a weight of [math]. 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 $n$ validators, let $\boldsymbol{\mathbf{w}}_{t}:=\left(w_{1,t},w_{2,t},\dots,w_{n,t}\right)$ denote a vector of non-negative weights or scaling factors, with $w_{t}:=\sum_{i=1}^{n}w_{i,t}$. The weighted majority rule, $f_{q}\left(w\right)$, or simply $f_{q}$, is defined as

[TABLE]

for $q\in[0.5,1]$. If all votes are equally weighted, i.e., if $w_{i,t}=1$ for all $i=1,\dots,n,t>0$, then (5) reduces to (1).

Using this notation, our goal is to determine the weights $\boldsymbol{\mathbf{w}}_{t}$ and the weighted majority rule $f_{\overline{q}_{t}}$ – or equivalently the quota $\overline{q}_{t}$ – that optimize the collective welfare $E_{t}$ given the selected committee $N_{t}$ of validators at time slot $t$, i.e.,

[TABLE]

This is the statement of the following Theorem which is due to [12] and in special instances due to [45, 56].

Theorem 3** (Optimal Weighted Voting Scheme,[12]).**

Consider a committee $N_{t}=\{1,2,\dots,n\}$ of validators with voting profiles $\boldsymbol{\mathbf{p}}_{t}=\left(p_{i,t},p_{2,t},\dots,p_{n,t}\right)$ that have been selected to vote on the proposed block in time slot $t>0$. Then, given $\alpha$ and the collective welfare parameters $\ell_{a},\ell_{r}$ in Table I, the decision rule that maximizes the collective welfare, cf. (6), is given by the weighted majority rule $f_{\overline{q}_{t}}$, with quota

[TABLE]

Proof.

To solve (6), we will control the decision rule $f_{q}$ in (2). Then, the optimal quota and individual weights in (7) and (8) will follow naturally. To see this, we expand (2) using (4) which gives

[TABLE]

where we used that $p_{i,t}$ denotes the probability of a correct decision, cf. (3). Our control variable to optimize the expected collective welfare in the previous equation is the decision rule $f_{q}$. It is immediate, that a general decision rule $f$ which maximizes $E_{t}$ is given by the following condition: for each decision profile $\boldsymbol{\mathbf{x}}_{t}\in X=\{-1,1\}^{n}$ append every block for which

[TABLE]

and reject it otherwise. The rule compares the contribution of the decision profile $\boldsymbol{\mathbf{x}}_{t}$ to the expected collective welfare if it is accepted (left hand side) to its contribution if it is rejected (right hand side) and returns the outcome that yields the maximum contribution. This establishes its optimality. It remains to translate this rule into a form decision rule in the form of (5) from which we will be able to deduct the optimal quota and weights. By grouping similar terms, we can rewrite (9) as

[TABLE]

and by taking the natural logarithm

[TABLE]

where we used that the function $\ln$ is monotone increasing. To proceed, we will use the transformations $y_{i}:=\left(x_{i}+1\right)/2$, so that

[TABLE]

and $z_{i}:=\left(1-x_{i}\right)/2$, so that

[TABLE]

Using this notation, we may rewrite the last inequality as

[TABLE]

Now, since $y_{i}-z_{i}=x_{i}$, we obtain that

[TABLE]

where the left hand side equals the left hand side of (5) with $w_{i,t}:=\ln{\left(\frac{p_{i,t}}{1-p_{i,t}}\right)}$. This establishes (8). To obtain (7), it remains to bring the right hand side of this inequality in the form of (5). This is equivalent to determining $\overline{q}_{t}$ so that the following equality holds

[TABLE]

Solving for $\overline{q}_{t}$ yields (7). ∎

Remark 4**.**

Based on the findings of Theorem 3 about the optimal quota and weights, cf. cf. (7) and (8), we have the following remarks.

• •

The optimal quota (7) depends on the validators’ profiles and hence, it may vary between different time slots $t>0$. Also, it may vary according to the values of the parameters $\alpha,\ell_{r},\ell_{a}$. For instance, the selection $\alpha=1/2$ neutralizes the bias due to assumptions on the distribution of valid versus invalid blocks whereas the selection $\ell_{r}=\ell_{a}$ neutralizes the bias due to differences in perceived network costs/rewards. In this way, Theorem 3 maximizes the collective welfare – or equivalently, the probability of consensus on the correct decision – by an easily adaptable and dynamic decision rule.

• •

In blockchain applications, it may be desirable to enforce certain restrictions, as for example that the required weighted majority will be no less than $2/3$ of the total weights or that each individual weight will be no less than some threshold value. As [56, 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 (8) will improve the probability of a correct outcome compared to unweighted decision making.

• •

For any voting profile $p\in\left(0,1\right)$, the optimal weight $w=\ln{\left(p/\left(1-p\right)\right)}$ is given in Figure 1.

For voting profiles $p<0.5$, the weight is negative which motivated our selection of suspending validators with profiles less that $0.5$. Intuitively, this means that these validators behave more than $50\%$ of the time not as expected and hence have an adverse impact to the consensus mechanism. Such validators could be even replaced by a random coin (which would be correct $50\%$ of the time). By properly initializing and suspending profiles above the $0.5$ threshold, such mathematically trivial situations can be avoided. This is discussed in more detail in Section VI.

• •

On the other hand, the optimal weights increase steeply as the voting profiles approach $1$. For instance, a validator with voting profile $p_{1}=0.9$ has an optimal weight $w_{1}\approx 2.2$, whereas a validator with voting profile $p_{2}=0.99$ has an optimal weight $w_{2}\approx 4.6$. In concrete terms, this means that a $10\%$ improvement in the validator’s voting profile resulted in a more than $100\%$ improvement in the validator’s optimal weight. In this way, the weighting mechanism disproportionally punishes even the slightest deviations from the optimal behavior and hence, incentivizes validators to behave correctly as consistently as possible. This feature can be utilized to enforce the socially desired outcome of almost zero failures in the consensus mechanisms.

• •

Finally, note that for applications, (5) can be simplified as follows. First, by dividing both sides with $w_{t}$, we can normalize the weights to sum up to $1$, i.e. $w^{\prime}_{i,t}:=w_{i,t}/w_{t}$ for $i=1,2,\dots,n$. Second, by letting $y_{i}=\left(x_{i}+1\right)/2$ as in the proof of Theorem 3, with $y_{i}=1$ if $x_{i}=1$ and $y_{i}=0$ if $x_{i}=-1$, we can rewrite (5) as

[TABLE]

or equivalently as

[TABLE]

Since $\sum_{i=1}^{n}w^{\prime}_{i,t}=1$, dividing both sides by $2$ yields the approval condition

[TABLE]

which is more handy than (but equivalent to) (5) and can be hence used for applications. This is done in Example 3 and Example 9 below.

Example 3** (Continued).**

Assume for simplicity that $\alpha=1/2$ and that $\ell_{r}=\ell_{a}$. In this case, the optimal rule is simple weighted majority, i.e., $\overline{q}=1/2$, or by substituting in (5), $f_{\overline{q}}\left(\boldsymbol{\mathbf{x}}\right)=1$ if $\sum_{i=1}^{n}w_{i}x_{i}\geq 0$ (dependence on $t$ is omitted to simplify the notation). Using (8) and normalizing the weights to sum up to $1$, we obtain $\boldsymbol{\mathbf{w}}=\left(0.392,0.392,0.072,0.072,0.072\right)$. With these choices, the probability of approving a valid block is approximately $0.927$ as shown in Table II.

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 ($2$ out of $3$) of the remaining validators approve the block (remaining $6$ columns of decision profiles). The probabilities of decision profiles $\boldsymbol{\mathbf{x}}_{t}$ with $f_{\overline{q}_{t}}\left(\boldsymbol{\mathbf{x}}_{t}\right)=1$ sum up to approximately $0.927$ as claimed

[TABLE]

The weights $\boldsymbol{\mathbf{v}}_{t}=\left(1/3,1/3,1/9,1/9,1/9\right)$ 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 $2/3$-weighted majority, the weights given by (8) may not be optimal anymore. However, as [56] 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 $2/3$-majority is $0.81$ with the $\boldsymbol{\mathbf{w}}_{t}$ weights and approximately $0.85$ with the $\boldsymbol{\mathbf{v}}_{t}$ weights.

The ProcessSlot procedure in Algorithm 1 executes the weighted voting algorithm in each slot $t$. First, the validators and a block proposer are selected according to the underlying PoS protocol (as part of the PoSGetCommittee procedure). The committee can be a random sample or deterministic subset taken from the entire validator set, or it can be the validator set in its entirety. For example, in Delegated Proof of Stake as implemented in TRON and EOS.IO, PoSGetCommittee would return the set of superdelegates. Next, the block proposed by the block proposer is retrieved and stored in the variable $B$ – if no valid block has been proposed, then we assume that the value null is stored in $B$. Once the committee has been formed and a valid block has been proposed, we retrieve for each committee member the block that they voted for using the CollectVotes procedure. We then check in ProcessVotes whether the validators voted for $B$ – if so, we record their vote as a $1$, and as a $-1$ otherwise. Next, the weighted voting procedure444The function that determines the optimal quota is given in a general form (line 26) to account for implementations with a rule different from the one proposed in (7), as e.g., a constant $2/3$-majority rule. is applied independent of the underlying PoS protocol – if a sufficient number of committee members voted for the $B$, then it is committed and appended to the blockchain. 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 of the PoS protocol and on the other hand can be implemented and reverted with minimal cost to the users.

IV 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. The updating scheme may considerably vary depending on the desired result: e.g., in [62], a reputation system is proposed in which reputation increases according to a sigmoid function when nodes vote correctly and decreases sharply (to [math]) 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 parametrizable 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.

Here, $\delta>0$ is a (small) number subject to the exact protocol parametrization. Apart from the efficiency properties of the MWU algorithm that are well known, see [2, 47, 9] and references therein, this scheme can leverage the prevailing network conditions and adjust the updates accordingly. This can be realized by replacing $\delta$ and/or $\ell_{r},\ell_{a}$ with sequences of updating parameters, $\left(\delta_{t},\ell_{r,t},\ell_{a,t}\right)_{t>0}$. The proposed scheme for updating validators’ voting profiles is given for completeness in Algorithm 2. If a new node comes online ($T$ is the slot when it does), it runs the MWInitialize procedure to get the voting profiles consistent with the rest of the network. Once this has been completed, the function MWUpdate is executed every slot to update the voting profiles. If a validator’s profile drops below 0.5, they are removed from the set – this happens in line 20. Similarly, new validators may be added in each round, depending on the protocol implementation. This processed in line 23. The min in line 14 ensures that the voting strength of a single validator cannot go to infinity (after all, if $p(i)$ approaches 1 then $w_{i}$ approaches $\infty$ as per line 17 in Algorithm 1).

IV-A Tolerance of Validator Faulty Behavior

Before testing the weighted voting and MWU algorithms numerically in the Section V, we study analytically the effect of the updating scheme on the validators’ profiles. Due to the parametric nature of the proposed algorithm, the question that naturally arises from the validators’ perspective is the following: what is the threshold of faulty behavior that can be sustained by the algorithm without harming my profile? In other words, what is the minimum percentage of time that a validator should strive to behave properly in order to sustain or improve their voting profile.

To explore this question, we first introduce some notation. Let $q\in[0,1]$ denote the percentage of time – measured in time slots, cf. Section II – that a (tagged) validator behaves according to the protocol, i.e., votes as expected by default, and let $q_{1}\in[0,1]$ denote the percentage of time that this validator does not vote on valid blocks (e.g., because they accidentally drop offline when it is their turn to vote). Accordingly, it must be that $q+q_{1}\leq 1$, with $1-q-q_{1}\in[0,1]$ denoting the percentage of time that the validator votes on the approval of invalid blocks. Finally, let $p_{0}$ denote the starting profile of the validator at the period under scrutiny and for any time frame $T>0$, let $p_{T}$ denote the validator’s profile at time $T$. Our aim is to obtain necessary and sufficient conditions on $q$ and $q_{1}$, so that the validator will improve or sustain their initial voting profile, i.e., $p_{T}\geq p_{0}$, where $p_{T}$ depends on the validator’s voting behavior via $q$ and $q_{1}$. Typically, we will be interested in large time periods, $T\gg 0$, that properly reflect the validator’s voting behavior as expressed by $q$ and $q_{1}$. However, the result of Theorem 6 remains correct for any $T>0$.

Theorem 6**.**

Consider the updating scheme in Table III with parameters $\delta,\ell_{r},\ell_{a}>0$ such that $\ell_{r}\ll\ell_{a}$ and $\delta\in\left(0,1\right)$, (typically $\delta$ is a small number close to [math]). A validator who follows the protocol $q\cdot 100\%$ of the time and does not vote on valid blocks $q_{1}\cdot 100\%$ of the time, with $q,q_{1}\in[0,1]$ and $q+q_{1}\leq 1$, will improve upon their initial profile if and only if

[TABLE]

where $c_{1}:=\left(1-\frac{\ln{\left(1+\delta\right)}}{\ell_{a}\ln{\left(1-\delta\right)}}\right)^{-1}$ and $c_{2}:=1-\ell_{r}/\ell_{a}$ are positive constants that depend on the updating parameters $\delta,\ell_{r}$ and $\ell_{a}$.

Proof.

The positivity of $c_{1}$ and $c_{2}$ follows directly from the assumptions. Indeed, $\ell_{r}<\ell_{a}$ implies that $\ell_{r}/\ell_{a}<1$ and hence, that $c_{2}>0$. Similarly, $\delta\in\left(0,1\right)$ implies that $\ln{\left(1-\delta\right)}<0$ and $\ln{\left(1+\delta\right)}>0$ and hence, that $c_{1}>0$ as the inverse of the sum of two positive terms (in particular, $c_{1}<1$).

Concerning (12), let $p_{0}$ denote the validators initial voting profile and let $p_{T}$ denote the validator’s voting profile after $T$ time slots. Then, given that $q$ denotes the fraction of time slots in which the validator voted correctly and $q_{1}$ the fraction of time slots in which the validator did not approve a valid block, we have that

[TABLE]

Hence, $p_{T}\geq p_{0}$ if and only if $\left(\left(1+\delta\right)^{q}\left(1-\delta\right)^{\left(\ell_{r}q_{1}+\ell_{a}\left(1-q-q_{1}\right)\right)}\right)^{T}\geq 1$. Since, the basis term is positive by assumption, we may take the natural logarithm of both sides to obtain the equivalent condition

[TABLE]

Using that $\left(1+\delta\right)>1$ and some standard algebraic operations, we can solve the last inequality for $q$ to obtain the necessary and sufficient condition

[TABLE]

which concludes the proof. ∎

Remark 7** (Policy Implications).**

The result of Theorem 6 can be utilized in the design policy of the updating algorithm to enforce certain requirements in the validators’ realized correct behavior, $q$. To see this, we first observe that $c_{1}$ can be rewritten as

[TABLE]

Since $\delta$ is typically a small positive number, e.g. $\delta=10^{-3}$ and $\ell_{a}$ is a positive number large enough to represent the potential losses from appending an invalid block to the blockchain, $c_{1}$ gets arbitrary close to, but strictly less than $1$ for increasing values of $\ell_{a}$. Moreover, for large values of $\ell_{a}$ and small values of $\ell_{r}$, $c_{2}:=1-\ell_{r}/\ell_{a}$ is also close to, but strictly less than $1$. This implies that $1-\varepsilon<c_{1}c_{2}<1$ for some relatively small $\varepsilon>0$. Hence, using that $q+q_{1}\leq 1$, we may rewrite (12) as

[TABLE]

This gives a lower bound on $q$ that does not depend on $q_{1}$. It is obvious that if the parameters $\delta,\ell_{r},\ell_{a}$ are selected in a way to push $c_{1}$ close to $1$, then a validator will have to vote consistently correctly to retain or improve their voting profile. In general, this shows the advantages of the parametric approach and the flexibility that it conveys to the policy makers or consensus designers (in case of public, permissionless blockchains) to enforce desired outcomes or even to dynamically adapt the consensus algorithm in response to prevailing network conditions.

V Numerical Tests & Practical Use Cases

To visualize the proposed scheme, we study some instantiations of the weighted voting and MWU algorithms. Before going into the details of each case, the following hold in general.

• •

Adversarial model: an adversary blocks $v\%$ of the votes, either by abstaining (accidentally or intentionally) or by censoring other validators. To demonstrate the efficiency of the model in extreme – or worst case – conditions, we show simulations for $v=40\%,50\%$ and $60\%$. For lower values of $v$, i.e., for less adversarial power, the results are similar (better) and thus omitted.

• •

Parameter choice: $\alpha$, the prior probability that a proposed block is invalid, is set to $1/2$. This choice neutralizes the bias due to assumptions on the distribution of valid-invalid blocks in (7) and corresponds to the most general model. To capture that costs from approval of invalid blocks are higher than costs from rejection of valid blocks, we select $\ell_{a}=12\gg 10^{-2}=\ell_{r}$. The resulting graphs (recovery times) are robust in a wide range of these parameters. Yet, very low values of $\ell_{a}$ may lead to unwanted behavior: validators who are commonly off-line may still improve their profiles despite not voting on valid blocks. Finally, the updating parameter $\delta$ has been chosen according to the related literature [2, 9]. Different values of $\delta$ affect the rate of convergence of the profiles.

• •

Simulation environment: The numerical results have been established in MATLAB R2018b. The simulations validate the algorithms for resuming consensus, cf. Figures 2 and 3 and for updating a validator’s profile, cf. Figures 4 and 5. Further issues related to scalability and computational complexity on a proper – or simulated – blockchain are discussed in Section VI.

Figure 2 illustrates a scenario with an adversary blocking $40\%$ of the votes. At the start of the attack, all $n$ validators555The exact number does not change the results. For simplicity, we used $n=100$. have a voting profile $p=0.9$. We examine two choices of the updating parameter $\delta=10^{-3}$ (red) and $\delta=2\times 10^{-3}$ (blue). In both cases, $\alpha=1/2$ and $\ell_{r}=10^{-2},\ell_{a}=12$.

The depicted curves indicate that the weighted approval votes (vertical axis) rise above the $2/3$ majority threshold666While the optimal quota, cf. (7), remains slightly above $1/2$, we consider the $2/3$-majority rule which is currently implemented in PoS protocols. for both cases. The pace is different and depends on the selection of $\delta$. The sharp bends in both lines correspond to the point in which the scores of voting validators numerically reach $1$. 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 $40\%$ resume voting. Specifically, the exact formula for updating their profiles is

[TABLE]

where $p^{\prime\prime}_{i,t+1}$ is the value calculated by Table III. This formula ensures that $p_{i,t}$ remains in $[0.5,1)$.

Remark 8**.**

To avoid the numerical instability at $p=1$ – for which the denominator at $\ln{\left(1/\left(1-p\right)\right)}$ becomes equal to [math] – we need to restrict profiles away from $1$. Specifically, to implement and test this scheme, we require that voting profiles do not exceed $1-\epsilon$ for some very small $\epsilon>0$. However, due to the steep increase of the optimal weights that was mentioned in Remark 4, the actual value of the imposed threshold $\epsilon$ matters and it should be chosen to be numerically close to [math]. Moreover, again due to the disproportional increase of the optimal weights for profiles close to $1-\epsilon$, validators who achieve this threshold (and remain at it by continuing to vote correctly after reaching it), have disproportionally higher power to influence the consensus outcome.

As a comparison, Figure 3 illustrates the process of resuming approval of blocks in the same scenario but with an adversary controlling $50\%$ of the stake (left panel) and $60\%$ of the stake (right panel). The results indicate a very similar recovery pattern, cf. Figure 2, independently of the initial stake of the non-voting validators. The evolution of a validator’s voting profile is illustrated in Figure 4. In the depicted scenario, the validator’s initial profile is $0.9$. The validator votes correctly $80\%$ of the time, but drops $10\%$ of the time off-line, and votes on invalid blocks another $10\%$ of the time. Again, we examine two cases for different values of the update parameter, $\delta=2\times 10^{-2}$ (left panel) and $\delta=10^{-2}$ (right panel).

While the patterns differ, in both depicted panels the voting profile falls due to the regular incorrect votes. We remark, that lower values of $\ell_{a}$ would result in upwards sloping curves (not depicted here) implying that a validator could regularly vote incorrectly and still improve their voting profile. Similarly, higher values of $\delta$ 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 $\ell_{r}$.

Finally, Figure 5 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 $10\%$ of the time – in which they go offline. Again, the two panels correspond to different values of $\delta$.

In both cases, the pattern is linear (the sharp bends correspond to the occasional drops) with a slope that can be adjusted by the choice of $\delta$. In sum, the simulations support the versatility of the proposed scheme and leave the exact parametrization (static or dynamic) subject to each protocol’s implementation and scope.

V-A Use Case: Ethereum Blockchain with Casper FFG

To further test the proposed scheme in a potential practical scenario, we consider the implementation of weighted voting in Ethereum’s Casper the Friendly Finality Gadget (FFG) as a PoS overlay on top of the PoW main chain[21]. This is a hybrid consensus system in which, roughly, PoS validators – stakers – vote to confirm (validate) blocks that have been proposed by “conventional” PoW miners at regularly-occurring checkpoints. To become a validator, a user has to deposit a chosen amount of ETH, Ethereum’s native cryptocurrency. If more than two thirds of the validators (where each validator is weighted proportionally to the size of their deposit) vote to approve a given checkpoint block, then it is considered justified, and if two checkpoint blocks in a row are justified then the first block is considered finalized. Ethereum nodes will never drop finalized blocks during a chain reorganization, so finalization provides an additional layer of security to the users. If more than one third of the validators go offline or are subjected to a network partition or eclipse attack, then checkpoints cannot be finalized. The system eventually recovers in the following way: after each checkpoint, those validators who did not vote are penalized which means that their fraction of the total deposit decreases. Eventually, their deposit fraction will fall below one third – hence, the voting validators regain a two-thirds supermajority and the ability to finalize. Of course, it would be harsh on the non-voting validators if their deposits were shrunk quickly during a network partition on eclipse attack, which would by itself disincentivize potential validators. The penalties are therefore initially very mild, but they become harsher over time. This is illustrated in Figure 6.

The main contribution of the currently proposed weighted voting scheme in Ethereum’s Hybrid Casper Protocol setting is that it enables the protocol to recover without hurting the deposits of the validators. Instead, validators who come back online eventually regain their voting profile without any financial losses. This also allows for faster recovery during network partitions: although network partitions that last for more than a day are extremely rare, a quick recovery that is achieved by slashing the deposits of offline validators may discourage potential validators from depositing.

The practical advantages of weighted voting are achieved without affecting either the underlying PoW blockchain or the PoS checkpoint finalization protocol. Instead, it operates within the selected committees and hence affects in a minimal way any suggested/existing scheme that is functional on the blockchain. This means that this scheme can be launched and reverted with minimal impact on client implementations and updates.

V-B Use Case: Incentives and Risk Mitigation in Proof of Stake Protocols

Several current PoS proposals including Ouroboros [33, 18], Casper FFG [20, 19], and Delegated Proof of Stake (DPOS) as implemented in EOS.IO, suggest the following properties.

P1:

a limited number of pools or committee members, which is achieved through a minimum deposit for each potential validator.

P2:

a fixed period (number of protocol epochs) of time for which the staked deposit will remain locked.

As we discuss in the following, weighted voting and updating schemes become particularly relevant under these conditions. Up to now, we have assumed that the PoS reward mechanism is retained, i.e., that validators are rewarded proportionally to their stake. However, if there are large discrepancies between the voting profiles, validators with high voting profiles contribute more to the consensus than validators with lower profiles. This may raise issues about the distribution of staking rewards and the adopted reward scheme.

To deal with such issues in a similar setting of decentralized multi-agent decision-making, [7] and [3] study incentives under the conventional reward scheme that gives to the participating agents their Shapley [55, 57] or Banzhaf values [11, 25]. In blockchain applications, the relevant question to address is whether the decision scheme together with the reward scheme create incentives for validators to merge, split or annex their deposits to larger pools[3]. [7] quantify the potential profit from creating various identities to participate in the weighted voting mechanism and show that given the number $n$ of participating agents, a Sybil attack cannot earn to a potential adversary more than $2n/\left(n+1\right)\approx 2$ times their initial values. Moreover, both [7] and [3] demonstrate that it is computational difficult, i.e., NP-hard, to find such profitable manipulations (mergers or splitters).

These findings are promising and suggest that reward schemes that have been developed in the context of traditional coalitional games can be used to incentivize proper behavior in the consensus mechanisms of blockchain protocols. By using properties P1.-P2. as above, we significantly mitigate the related risks. Indeed, setting a number of allowed validating pools (P1) together with a large enough minimum required deposit increase the difficulty for splitters. Yet, taking these precautions to the other extreme takes its toll on decentralization and hence such measurements should be exercised to a limited extent. In any case, the fixed period for which deposits remain locked (P2), seems to significantly reduce the potential for movements in the short run at no significant tradeoffs with other blockchain protocol design principles.

Eclipse Attacks

The weighted voting scheme is engineered to accelerate recovery of consensus and prevent the blockchain from stalling when a fraction of validators is off-line or in general does not vote. Validators that continue to vote increase their voting profiles and hence, their power to influence the consensus outcome, whereas the voting profiles of non-voting validators deteriorate. Furthermore each validator’s optimal weight depends only on that validator’s voting behavior (or profile) and hence, can be computed independently of the committee in which this validator participates. However, this is not true for the relative power of each validator in each committee. An example is given below.

Example 9**.**

Consider a validator $i=1$ with profile $p_{1,t}=0.99$ and two different committees:

Committee in $t=1$:

$n=10$ validators with voting profiles, $\boldsymbol{\mathbf{p}}_{1}=\left(0.99,0.7,\dots,0.7\right)$,

Committee in $t=2$:

$n=10$ validators with voting profiles, $\boldsymbol{\mathbf{p}}_{2}=\left(0.99,0.95,\dots,0.95\right)$.

As in the numerical tests, we will assume that $\ell_{r}=10^{-2},\ell_{a}=12$ and $\alpha=1/2$ for both committees. Applying (7) on these values yields the optimal quotas $\overline{q}_{1}=0.604$ for $t=1$ and $\overline{q}_{2}=0.54$ for $t=2$. The unnormalized optimal weight of validator $1$ is equal to $w_{1}=\ln{\left(0.99/\left(1-0.99\right)\right)}=4.595$ in both committees. However, their normalized weights $w^{\prime}_{i,t},t=1,2$ which will be used to assess the block approval condition (11), are equal to $w^{\prime}_{1,1}=0.376$ and $w^{\prime}_{1,2}=0.148$ respectively. This shows that validator $1$ is better off in the first committee.

To reach this conclusion, the second committee was selected with much worse – in terms of their voting profiles – validators. However, similar discrepancies in validator $1$’s optimal normalized weight can be observed even in the presence of only $2$ equally good validators.

Committee in $t=3$:

$n=10$ validators with voting profiles, $\boldsymbol{\mathbf{p}}_{1}=\left(0.99,0.99,0.95,0.7,\dots,0.7\right)$.

In this case, the optimal quota $\overline{q}_{3}$ is equal to $\overline{q}_{3}=0.57$ and validator $1$’s optimal normalized weight is equal to $w^{\prime}_{1,3}=0.254$. Similarly, validator $2$’s optimal normalized weight $w^{\prime}_{2,3}$ is also equal to $0.254$ and validator $3$’s optimal normalized weight is equal to $0.163$. This highlights the power of these $3$ validators to decide the consensus outcome in committee $3$.

The previous example reveals two interesting facts. On the one hand, the dynamic adjustments in the optimal quota and validator’s normalized weights create a consensus mechanism with intriguing properties when compared to static alternatives. The versatility of this algorithm under the concurrent theoretical guarantees that it optimizes the probability of a correct decision, or more accurately the expected collective welfare, motivate further research both from theoretical and practical perspectives concerning its adoption.

On the other hand, the dependence of the validators’ relative power on the profiles of the other committee members creates a incentive for malicious behavior that should be taken into account. Specifically, since validators’ relative power increases as the profiles of the other committee members decrease, this motivates adversarial validators to perform eclipse attacks and prevent other validators from voting properly. However, for such attacks to be profitable, the attackers needs to sustain their profile which means that they need to keep voting properly. Moreover, the actual outcome on the overall collective welfare will depend on the trade-off between the size of the attacker’s stake and the size of the eclipsed validator’s stake along with detection and potential penalties on such behaviors. In any case, fixing parameters as in P1-P3 seems to reduce the arsenal of potential attackers but a precise verdict on whether such attacks can be profitable depends on the exact protocol parametrization and should be examined separately in every case of adoption.

VI Design & Limitations

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

Defense against known attacks

To defend against consensus level attacks, current PoS proposals leverage the fact that non-voting nodes can be identified and penalized [19, 5]. Yet, these actions are ineffectual against adversaries who can censor other validators or replenish their own stake and withstand the penalties to retain more than the required consensus-quota of the total stake [30, 50]. Although pessimistic, the 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. Further, consensus mechanisms that rely on PoS selection are vulnerable to flash or blindsiding attacks conducted by entering nodes [15, 23] or to accidental faults such as network latency, bad connectivity or simple negligence. Weighted voting 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

A likely contentious assumption of the present model is that proposed blocks can be identified as valid or invalid777This is a chicken-egg problem: if we can identify the “canonical” blocks, then we can improve consensus with a scheme as the one proposed here. But in blockchains, the “canonical” blocks are precisely the ones for which consensus was reached.. 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 their 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 [53, 52].

Updating scheme & Computational Complexity

Dealing with the issue of valid-invalid blocks 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 their previous voting profile. This motivates updating profiles by two variables $s_{i,t}$ and $l_{i,t}$ representing short-term and long-term voting respectively. In general, the advantages of the here employed generalized MWU algorithm – e.g., convergence rates and tight bounds on its overall performance [2] – can be further exploited alongside stability properties of opinion dynamics in networks [43] to yield more robust results also in the present context. Finally, the computational complexity of initializing, storing and updating validators’ profiles does not exceed the complexity of performing the same functions on validators’ stakes and hence it is not expected to have a significant impact on the overhead of any consensus that keeps track of validators’ stakes. This intuition is even more likely to materialize within the framework of most state of the art proposals, like EOS.IO, Casper and Ouroboros that promote consensus systems with a limited number delegates, staking pools or potential validators.

Entry & threshold voting profiles

The levels at which voting profiles are initialized and suspended are crucial, since they can incentivize or prevent Sybil attacks. The exact parametrization can be case-depend, justified by simulations or incorporate prior information for each entering validator, e.g., reputable financial institution versus unknown private staker. The present choice to initialize voting profiles at $0.5$ and to require that they remain in $[0.5,1)$ for all $t\geq g>0$, where $g$ denotes a potential initial grace period, is supported by both intuitive and theoretical arguments. From a mathematical perspective, the initial choice of $0.5$ represents an uninformative prior on an entering’s validators voting profile. Similarly, the reason for the upper bound is purely numerical, namely to avoid the instability in $\ln{\left(p_{i,t}/\left(1-p_{i,t}\right)\right)}$ if $p_{i,t}=1$. In contrast, the suspension of validators with voting profile – or probability of making a correct decision – lower than $0.5$ is more fundamental. [12] 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 one triggers 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 [20]. 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.

Future implementation

Currently, the proposed scheme seems more attractive for systems with low numbers of staking nodes: these may be permissioned and delegated PoS blockchains or blockchains with fixed number of stake pools. More closely related to this spirit are the proposals of [19, 33, 1, 42]. In these settings, the computational complexity of implementing a profiling system is not an issue. However, this is also expected to remain true in the general case of permissionless blockchains, since extra data storage is limited to one additional value per validator and computations to update profiles are linear in the size of the committees. Light on this issues will be shed by future implementations on simulated blockchains and if successful, on properly designated testnets of these blockchains. In the core of these studies will be the understanding of issues related to network conditions (latency, scalability), computational complexity to store and retrieve profiles, indirect economic effects on cryptocurrency prices [34], and the testing of different updating schemes in terms of their convergence rates and efficiency bounds.

VII 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 their so far contribution to the protocol – and defined the proper mathematical framework to apply the results of [12] 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.