status-im
/
research
mirror of https://github.com/status-im/research.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Started on economics paper

This commit is contained in:
Vitalik Buterin 2017-08-27 09:55:46 -04:00
parent 96e8081b30
commit 4b8248b7c3
4 changed files with 120 additions and 160 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
papers/casper-basics/casper_basics.tex
View File

@ -3,20 +3,17 @@
Vitalik Buterin \\
Ethereum Foundation}
\documentclass[12pt, final]{article}
%\input{eth_header.tex}
\usepackage{color}
\newcommand*{\todo}[1]{\color{red} #1}
\newcommand{\eqref}[1]{eq.~\ref{#1}}
\newcommand{\figref}[1]{Figure~\ref{#1}}
\usepackage{amsthm}
\newtheorem{theorem}{Theorem}
\newtheorem{definition}{Definition}
\usepackage{graphicx}
\graphicspath{{figs/}{figures/}{images/}{./}}

2
papers/casper-economics/appendix.tex
View File

@ -4,7 +4,7 @@
\section{Safety Failure}
\label{app:safetyfailure}
\TODO{Put the full description/definition of conflicting blocks here.}
\todo{Put the full description/definition of conflicting blocks here.}

BIN
papers/casper-economics/casper_economics_basic.pdf
View File

Binary file not shown.

269
papers/casper-economics/casper_economics_basic.tex
View File

@ -1,202 +1,172 @@
\title{Incentives in Casper the Friendly Finality Gadget}
\author{
Vitalik Buterin \\
Ethereum Foundation
}
Ethereum Foundation}
\documentclass[12pt, final]{article}
\input{eth_header.tex}
%\input{eth_header.tex}
\usepackage{color}
\newcommand*{\todo}[1]{\color{red} #1}
\newcommand{\eqref}[1]{eq.~\ref{#1}}
\newcommand{\figref}[1]{Figure~\ref{#1}}
\usepackage{amsthm}
\newtheorem{theorem}{Theorem}
\newtheorem{definition}{Definition}
\usepackage{graphicx}
\graphicspath{{figs/}{figures/}{images/}{./}}
%% Special symbols we'll probably iterate on
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\newcommand{\epoch}{ \mathscr{E} }
%\newcommand{\hash}{\ensuremath{ \mathscr{H} }}
%\newcommand{\epoch}{ {\footnotesize \textnormal{\textestimated} } }
% we will probably iterate on these symbols until we have a notation we like
\newcommand{\epoch}{\ensuremath{e}\space}
\newcommand{\hash}{\textnormal{h}\space}
\newcommand{\epoch}{\ensuremath{e}\xspace}
\newcommand{\hash}{\textnormal{h}\xspace}
% symbols for the epoch and hash source
\newcommand{\epochsource}{\ensuremath{\epoch_{\star}}\space}
\newcommand{\hashsource}{\ensuremath{\hash_{\star}}\space}
%\newcommand{\epoch}{ \ensuremath{ \mathcal{E} } }
%\newcommand{\hash}{\ensuremath{ \mathcal{H} }}
\newcommand{\signature}{\ensuremath{\mathcal{S}}\space}
%\newcommand{\epoch}{ \ensuremath{ \mathds{E} } }
%\newcommand{\hash}{\ensuremath{ \mathds{H} }}
\newcommand{\totaldeposit}{\textnormal{TD}\space}
\newcommand{\gamesymbol}{\reflectbox{G}}
\newcommand{\hashsource}{\ensuremath{\hash_{\star}}\xspace}
\newcommand{\epochsource}{\ensuremath{\epoch_{\star}}\xspace}
\newcommand{\msgPREPARE}{\textbf{\textsc{prepare}}\space}
\newcommand{\msgCOMMIT}{\textbf{\textsc{commit}}\space}
\newcommand{\signature}{\ensuremath{\mathcal{S}}\xspace}
% Symbols for the Last Justified Epoch and Hash
\newcommand{\epochLJ}{\ensuremath{\epoch_{\textnormal{LJ}}}\space}
\newcommand{\hashLJ}{\ensuremath{\hash_{\textnormal{LJ}}}\space}
\newcommand{\BIR}{\textsc{BIR}\xspace}
\newcommand{\BP}{\textsc{BP}\xspace}
\newcommand{\NCP}{\textsc{NCP}\xspace}
\newcommand{\NCCP}{\textsc{NCCP}\xspace}
\newcommand{\NPP}{\textsc{NPP}\xspace}
\newcommand{\NPCP}{\textsc{NPCP}\xspace}
% Symbols for the Last Finalized Epoch and Hash
\newcommand{\epochLF}{\ensuremath{\epoch_{\textnormal{LF}}}\space}
\newcommand{\hashLF}{\ensuremath{\hash_{\textnormal{LF}}}\space}
\newcommand{\totaldeposit}{\textnormal{TD}\xspace}
% Griefing Factor symbol
\newcommand{\GF}[1]{GF\left( #1 \right)\space}
\newcommand{\gamesymbol}{ \reflectbox{G} }
% Genesis block symbol
\newcommand{\Genesisblock}{\ensuremath{G}\space}
\newcommand{\msgPREPARE}{\textbf{\textsc{prepare}}\xspace}
\newcommand{\msgCOMMIT}{\textbf{\textsc{commit}}\xspace}
\newcommand{\epochLJ}{\ensuremath{\epoch_{\textnormal{LJ}}}\xspace}
\newcommand{\hashLJ}{\ensuremath{\hash_{\textnormal{LJ}}}\xspace} % we may not need this one
\newcommand{\epochLF}{\ensuremath{\epoch_{\textnormal{LF}}}\xspace}
\newcommand{\hashLF}{\ensuremath{\hash_{\textnormal{LF}}}\xspace} % we may not need this one
\newcommand{\GF}[1]{\mathds{GF}\left( #1 \right)\xspace}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Econ-specific symbols
\newcommand{\BIR}{\textsc{BIR}\space}
\newcommand{\BP}{\textsc{BP}\space}
\newcommand{\NCP}{\textsc{NCP}\space}
\newcommand{\NCCP}{\textsc{NCCP}\space}
\newcommand{\NPP}{\textsc{NPP}\space}
\newcommand{\NPCP}{\textsc{NPCP}\space}
\begin{document}
\maketitle
\begin{center} \vspace{-15pt} {\red{\today}} \end{center}
\begin{abstract}
We give an introduction to the incentives in the Casper the Friendly Finality Gadget protocol, and show how the protocol behaves under individual choice analysis, collective choice analysis and griefing factor analysis. We define a ``protocol utility function'' that represents the protocol's view of how well it is being executed, and show the connection between the incentive structure that we present and the utility function. We show that (i) the protocol is a Nash equilibrium assuming any individual validator's deposit makes up less than $\frac{1}{3}$ of the total, (ii) in a collective choice model, where all validators are controlled by one actor, harming protocol utility hurts the cartel's revenue, and there is an upper bound on the ratio between the reduction in protocol utility from an attack and the cost to the attacker, and (iii) the griefing factor can be bounded above by $1$, though we will prefer an alternative model that bounds the griefing factor at $2$ in exchange for other benefits.
We give an introduction to the incentives in the Casper the Friendly Finality Gadget protocol, and show how the protocol behaves under individual choice analysis, collective choice analysis and griefing factor analysis. We show that (i) the protocol is a Nash equilibrium assuming any individual validator's deposit makes up less than $\frac{1}{3}$ of the total, (ii) collectively, the validators lose from causing protocol faults, and there is a minimum ratio between the losses incurred by the validators and the seriousness of the fault, and (iii) the griefing factor can be bounded above by $1$, though we will prefer an alternative model that bounds the griefing factor at $2$ in exchange for other benefits. We also describe tradeoffs between protocol fairness and incentivization and fallbacks to extra-protocol resolution mechanisms such as market-driven chain splits.
We assume the "Casper the Friendly Finality Gadget" paper as a dependency.
\end{abstract}
\section{Introduction}
\label{sect:intro}
\todo{Probably do a little more filler here citing previous PoS literature.}
Some of the prior Proof-of-Stake systems are \cite{bentov2016pos,king2012ppcoin,vasin2014blackcoin}.
\todo{define blocks, epochs}
A epoch is defined as a period of 100 blocks. Epoch $k$ begins at block $k*100$ and ends at block $k*100 + 99$. A \emph{checkpoint} for epoch $k$ is a block with number $k*100 - 1$. In a perfect execution there will be exactly one checkpoint per epoch. Due to to network latency or deliberate attacks there may be multiple competing checkpoints.
\section{The Casper Protocol}
\section{Recap: The Casper Protocol}
\label{sect:casperprotocol}
In the Casper protocol, there is a set of validators, and in each epoch validators have the ability to send two kinds of messages:
$$\langle \msgPREPARE, \hash, \epoch, \hashsource, \epochsource, \signature \rangle$$
\begin{table}[h!bt]
\centering
\subfloat[\msgPREPARE format]{ \begin{tabular}{l l} \toprule
\begin{tabular}{l l}
\textbf{Notation} & \textbf{Description} \\
\midrule
\hash & the hash to justify \\
\epoch & the current epoch \\
\hash & a checkpoint hash \\
\epoch & the epoch of the checkpoint \\
$\hashsource$ & the most recent justified hash \\
$\epochsource$ & the epoch containing hash $\hashsource$ \\
\signature & signature from the validator's private key of the tuplet $(\hash,\epoch,\hashsource,\epochsource)$. \\
\bottomrule
\end{tabular} \label{tbl:prepare} }
$\epochsource$ & the epoch of $\hashsource$ \\
\signature & signature of $(\hash,\epoch,\hashsource,\epochsource)$ from the validator's private key \\
\end{tabular} \label{tbl:prepare}
\subfloat[\msgCOMMIT format]{ \begin{tabular}{l l} \toprule
$$ $$
$$\langle \msgCOMMIT, \hash, \epoch, \signature \rangle$$
\begin{tabular}{l l}
\textbf{Notation} & \textbf{Description} \\
\midrule
\hash & the hash to finalize \\
\epoch & the current epoch \\
\hash & a checkpoint hash \\
\epoch & the epoch of the checkpoint \\
\signature & signature from the validator's private key \\
\bottomrule
\end{tabular}
\label{tbl:commit} }
\caption{The schematic of the \msgPREPARE and \msgCOMMIT messages.}
\label{tbl:commit}
\label{fig:messages}
\end{table}
$$ $$
Each validator has a \emph{deposit size}; when a validator joins their deposit size is equal to the number of coins that they deposited, and from there on each validator's deposit size rises and falls with rewards and penalties. For the rest of this paper, when we say ``$\nicefrac{2}{3}$ of validators'', we are referring to a \emph{deposit-weighted} fraction; that is, a set of validators whose sum deposit size equals to at least $\frac{2}{3}$ of the total deposit size of the entire set of validators. We also use ``$\nicefrac{2}{3}$ Prepares'' and ``$\nicefrac{2}{3}$ Commits'' as shorthand for ``$\frac{2}{3}$ of deposit-weighted validators sent Prepares/Commits''.
The blockchain state maintains the \textit{current validator set} $V_c: v \rightarrow R^+$, a mapping of validators to their deposit sizes (non-negative real numbers) and the \textit{previous validator set} $V_p: v \rightarrow R^+$. The \textit{total current deposit size} is equal to $\sum_{v \in V} V_c[v]$, the sum of all deposits in the current validator set, and the \textit{total previous deposit size} is likewise equal to the $\sum_{v \in V} V_p[v]$. Validators can deposit $n$ coins to join both validator sets with deposit size $n$, and a validator with deposit size $n'$ can withdraw $n'$ coins with a delay. For any deposit or withdraw action to fully take effect, three checkpoints need to be finalized in a chain after the withdraw is included in that chain (validators get inducted to and ejected from the current validator set first, so after two finalized hashes, a validator will be in one validator set but not the other).
Every hash $\hash$ has one of three possible states: \emph{fresh}, \emph{justified}, and \emph{finalized}. Every hash starts as \emph{fresh}. The hash at the beginning of the current epoch converts from fresh to \emph{justified} if, during the current epoch $\epoch$, $\nicefrac{2}{3}$ Prepares are sent of the form
An \textit{epoch} is a range of 100 blocks (e.g. blocks 600...699 are epoch 6), and a \textit{checkpoint} as the hash of a block right before the start of an epoch. The \textit{epoch of a checkpoint} is the epoch \textit{after} the checkpoint, e.g. the epoch of a checkpoint which is the hash of some block 599 is 6.
\begin{equation}
\langle \msgPREPARE, \epoch, \hash, \epochsource, \hashsource, \signature \rangle
\label{eq:msgPREPARE}
\end{equation}
We will use ``$p$ of validators'' for any fraction $p$ (eg. $\frac{2}{3}$) as shorthand for ``some set of validators $V_s$ such that $\sum_{v \in V_s} V_c[v] \ge \sum_{v \in V_c} V_c[v] * p$ and $\sum_{v \in V_s} V_p[v] \ge \sum_{v \in V_p} V_p[v] * p$'' - that is, such a set must make up \textit{both} $p$ of the current validator set \textit{and} $p$ of the previous validator set. The ``portion of validators that did X'' refers to the largest value $0 \le p \le 1$ such that $p$ of validators (using the definition above) did X.
for some specific $\epochsource$ and $\hashsource$. A hash $\hash$ can only be justified if and only if its $\hashsource$ is already justified or finalized.
Additionally, a hash converts from justified to \emph{finalized}, if $\nicefrac{2}{3}$ Commits
\begin{equation}
\langle \msgCOMMIT, \epoch, \hash, \signature \rangle \; ,
\label{eq:msgCOMMIT}
\end{equation}
for the same \epoch and \hash as in \eqref{eq:msgPREPARE}. The $\hash$ is the block hash of the block at the start of the epoch. A hash $\hash$ being justified entails that all fresh (non-finalized) ancestor blocks are also justified. A hash $\hash$ being finalized entails that all ancestor blocks are also finalized, regardless of whether they were previously fresh or justified. An ``ideal execution'' of the protocol is one where, at the start of every epoch, every validator Prepares and Commits the first blockhash of each epoch, specifying the same $\epochsource$ and $\hashsource$. We wish to incentivize this ideal execution.
Every checkpoint hash $\hash$ has one of three possible states: \emph{fresh}, \emph{justified}, and \emph{finalized}. Every hash starts as \emph{fresh}. A hash $\hash$ converts from fresh to \emph{justified} if $\frac{2}{3}$ of validators send prepares for $\hash$ with the same $(\epoch, \hashsource, \epochsource)$ triplet. An ``ideal execution'' of the protocol is one where, at the start of every epoch, every validator prepares and commits the same checkpoint for that epoch, specifying the same $\epochsource$ and $\hashsource$; thus, in every epoch, that checkpoint gets finalized. We wish to incentivize this ideal execution.
Possible deviations from this ideal execution that we want to minimize or avoid include:
\begin{itemize}
\item Violating any of the two Casper Commandments. \cite{minslashing} To violate either Commandment is to forfeit one's \emph{entire deposit}.
\item Safety failures, i.e. two incompatible checkpoints getting finalized.
\item Liveness failures, i.e. a checkpoint not getting finalized during some epoch.
\end{itemize}
These are both failures \textit{of the protocol}. The next step from here is \textit{fault assignment} - if a failure of the protocol were to happen, determine what failures \textit{of individual validators} could have caused it, so that we can penalize them.
\subsection{Safety faults}
There exists a proof that any safety fault can only be caused by at least $\frac{1}{3}$ of validators violating one of the two Casper Commandments (``slashing conditions''), defined below:
\begin{enumerate}
\item[\textbf{I.}] \textsc{A validator shalt not publish two nonidentical Prepares with the same $\epoch$ value.}
\item[\textbf{I.}] \textsc{A validator shalt not publish two or more nonidentical Prepares for same epoch.}
This is equivalent to that each validator may Prepare to exactly one (\hash, \epochsource, \hashsource) triplet per epoch.
In other words, a validator may Prepare at most exactly one (\hash, \epochsource, \hashsource) triplet for any given epoch \epoch.
\item[\textbf{IIa.}] \textsc{A validator shalt not publish an Commit between a Prepare jump.}
\item[\textbf{II.}] \textsc{A validator shalt not publish an Commit between the epochs of a Prepare statement.}
Equivalently, a validator will not publish
Equivalently, a validator may not publish
% \item[\textbf{II.}] \textbf{\textsc{prepare\_commit\_consistency}}. A validator shalt not publish an incompatible Prepare/Comment pairing. Equivalently, ro4 a single hash $\hash$, a validator will not publish
\begin{equation*}
\begin{equation}
\langle \msgPREPARE, \epoch_p, \hash_p, \epochsource, \hashsource, \signature \rangle \hspace{0.5in} \textnormal{\textsc{and}} \hspace{0.5in} \langle \msgCOMMIT, \epoch_c, \hash_c, \signature \rangle \;,
\label{eq:msgPREPARE}
\end{equation*}
\end{equation}
where the epochs satisfy $\epochsource < \epoch_c < \epoch_p$.
\end{enumerate}
\item[\textbf{IIb.}] \textsc{A validator shall only publish compatible Prepare/Commit pairings.}
Hence, we can adequately penalize safety failures by simply taking away the deposits of any validator that violates either of the two slashing conditions.
Equivalently, for a single hash $\hash$, a validator shall only publish
\subsection{Liveness Faults}
Penalizing liveness faults is more difficult. If the only kind of faulty behavior that were possible is nodes going offline, then penalization would also be simple: find the validators that did not send prepares and commits during any epoch, and take away their deposits. However, there are several other faulty behaviors that are possible:
% \item[\textbf{II.}] \textbf{\textsc{prepare\_commit\_consistency}}. A validator shalt not publish an incompatible Prepare/Comment pairing. Equivalently, ro4 a single hash $\hash$, a validator will not publish
\begin{enumerate}
\item Preparing or committing too late
\item Preparing a different \hash from the hash prepared by most other validators.
\item Using a different \hashsource and \epochsource from that used by most other validators.
\item Network latency
\item A majority coalition finalizing a chain that does not include prepares or commits sent by those outside of some coalition (a ``censorship fault'')
\item A majority coalition waiting for other validators to prepare one \hash, and then preparing another \hash instead.
\item A majority coalition waiting for other validators to prepare with one \hashsource, and then preparing another \hashsource instead.
\end{enumerate}
\begin{equation*}
\langle \msgPREPARE, \epoch_p, \hash, \epochsource, \hashsource, \signature \rangle \hspace{0.5in} \textnormal{\textsc{and}} \hspace{0.5in} \langle \msgCOMMIT, \epoch_c, \hash, \signature \rangle \;,
\label{eq:msgPREPARE}
\end{equation*}
The list above is deliberately organized symmetrically, to illustrate a fundamental problem with attributing liveness faults known as \textit{speaker/listener fault equivalence}: given only a transcript of messages that were sent earlier, that contain a record of user B sending a message that shows the absence of an expected message from user A, this could arise because A was not speaking, or because B was not listening, and \textit{there is no way to tell the two apart}. In this case, (1) and (5) are indistinguishable, as are (2) and (6), and (3) and (7). Finally, all seven may be indistuiguishable from network latency.
where the epochs satisfy $\epochsource < \epoch_p \leq \epoch_c$.
What this means is that, in a liveness fault, we cannot unambiguously determine who was at fault, and this creates a fundamental tension between \textit{disincentivizing harm} and \textit{fairness} - between sufficiently penalizing validators who are malicious and not excessively penalizing validators who are not at fault. A protocol which absolutely ensures that innocent validators will not lose money must thus rely only on rewards, not on penalties, for discouraging non-uniquely-attributable faults, and so will only have a cryptoeconomic security margin equal to the size of the rewards that it issues. A protocol that penalizes suspected validators to the maximum will be one where innocent validators will not feel comfortable participating, which itself reduces security.
A third ``way out'' is punting to off-chain governance. If a fault could have been caused by either A or B, then split the chain in half, on one branch penalize A, on the other branch penalize B, and let the market sort it out. We can theorize that the market will prefer branches where malfeasant validators control a smaller portion of the validator set, and so on the chain that ``wins'' the validators that the market subjectively deems to have been responsible for the fault will lose money and the innocent valdidators will not.
[diagram]
% \item \textbf{\textsc{prepare\_req}}. A validator shalt not Prepare with a $\hashsource$ that is not \emph{justified}.
% \item \textbf{\textsc{commit\_req}}. If a validator Commits an unjustified hash, the validator is penalized.
%\item[\textbf{III.}] \todo{Don't we need another saying don't Commit on an unjustified hash?}
\end{enumerate}
%\item During some epoch, we do not get $\nicefrac{2}{3}$ Prepares for the same $(h, \hashsource, \epochsource)$ combination.
%\item During some epoch, we do not get $\nicefrac{2}{3}$ Commits for the $hash$ that received $\nicefrac{2}{3}$ prepares. \todo{there can be multiple hashes that received 2/3 prepares, right?}
\item By the end of epoch \epoch, the first blockhash of epoch \epoch is not 100\% justified or is not 100\% finalized.
\end{itemize}
All Prepares with an $\hashsource$ that is not justified is ignored.
All Commits from unjustified hashes are ignored.
Each validator only see the blockchain's own history, including messages that were passed in. \todo{Are Commits/Prepares stored on-chain?}
%In a history that contains some blockhash $H$, our strategy is to reward validators who Prepared and Committed $H$, and not reward prepares or commits for any hash $H^\prime \ne H$.
The blockchain state stores the latest justified epoch and hash, $\epochLJ$ and $\hashLJ$, and only rewards Prepares whose $\epochsource = \epochLJ$ and $\hashsource = \hashLJ$. These two techniques will help to coordinate validators toward Preparing and Committing a single epoch \epoch and hash \hash.
Let $\totaldeposit$ be the current \emph{total amount of deposited coins}, and $\epoch - \epochLF$ be the number of epochs since the last finalized epoch.
However, there must be some cost to triggering a ``governance event''; otherwise, attackers could trigger these events as a deliberate strategy in order to breed continual chaos among the users of a blockchain. The social value of blockchains largely comes from the fact that their progression is mostly automated, and so the more we can reduce the need for users to appeal to the social layer the better.
\section{Rewards and Penalties}
We define the following nonnegative functions, all of which return a nonnegative scalar with no units. Technically these values can exceed 1.0, but in practice they will be rarely exceed $0.01$:
We define the following nonnegative functions, all of which return a nonnegative scalar with no units. Technically these values can exceed 1.0; in any situation which appears to call for reducing some validator's deposit size to a negative value, the deposit size should instead simply be reduced to zero.
\begin{itemize}
\item $\BIR(\totaldeposit)$: returns the base interest rate paid to a validator, taking as an input the current total quantity of deposited coins.
@ -264,18 +234,16 @@ We are assuming there are $\frac{2}{3}$ Prepares for $(\epoch, \hash, \epochsour
\begin{table}[h!bt]
\centering
\subfloat[Preparing $\langle \epoch, \hash, \epochsource, \hashsource \rangle$ ]{ \begin{tabular}{l c} \toprule
\thead{Action} & \thead{Payoff} \\
\midrule
Preparing $\langle \epoch, \hash, \epochsource, \hashsource \rangle$
{ \begin{tabular}{l c}
\textbf{Action} & \textbf{Payoff} \\
Preparing & 0 \\
Not Preparing & $-\NPP - \NPCP(\alpha)$ \\
\bottomrule
\end{tabular}} \hspace{0.5in} \subfloat[Committing $\langle \epoch, \hash \rangle$ ]{ \begin{tabular}{l c} \toprule
\thead{Action} & \thead{Payoff} \\
\midrule
\end{tabular}} \hspace{0.5in} Committing $\langle \epoch, \hash \rangle$
{ \begin{tabular}{l c}
\textbf{Action} & \textbf{Payoff} \\
Commiting & 0 \\
Not Commiting & $-\NCP - \NCCP(\alpha)$ \\
\bottomrule
\end{tabular}
\label{tbl:commit} }
\caption{Payoffs for ideal individual behaviors.}
@ -291,7 +259,7 @@ To model the protocol in a collective-choice context, we first define a \emph{pr
U \equiv \sum_{k = 0}^{\epoch} - \log_2\left[ k - \epochLF \right] - M F \; .
\label{eq:utilityfunction}
\end{equation}
\TODO{the above equation might be able to simplifiable}
\todo{the above equation might be able to simplifiable}
Where:
@ -310,10 +278,8 @@ This can be justified in two ways. First, one can intuitively argue that a user'
Now, we need to show that, for any given total deposit size, $\frac{loss\_to\_protocol\_utility}{validator\_penalties}$ is bounded. There are two ways to reduce protocol utility: (i) cause a safety failure, or (ii) prevent finality by having $> \frac{1}{3}$ of deposit-weighted validators not Prepare or Commit to the same hash. Causing a safety failure requires violating one of the Casper Commandments (Section \ref{sect:casperprotocol}) and thus ensures immense loss in deposits. In the second case, in a chain that has not been finalized for $\epoch - \epochLF$ epochs, the penalty to attackers is at least,
\begin{equation}
\begin{split}
\min \left[ \NPP \left(\frac{1}{3}\right) + \NPCP\left(\frac{1}{3}\right), \NCP \left(\frac{1}{3}\right) + \NCCP\left(\frac{1}{3}\right) \right] &* \BP(\totaldeposit, \epoch - \epochLF) \\
\left(\frac{1}{3}\right) \min \left[ \NPP + \NPCP, \NCP + \NCCP \right] &* \BP(\totaldeposit, \epoch - \epochLF) \\
\end{split}
\min \left[ \NPP \left(\frac{1}{3}\right) + \NPCP\left(\frac{1}{3}\right), \NCP \left(\frac{1}{3}\right) + \NCCP\left(\frac{1}{3}\right) \right] * \BP(\totaldeposit, \epoch - \epochLF) \\
\left(\frac{1}{3}\right) \min \left[ \NPP + \NPCP, \NCP + \NCCP \right] * \BP(\totaldeposit, \epoch - \epochLF) \\
\end{equation}
To enforce a ratio between validator losses and loss to protocol utility, we set,
@ -321,7 +287,7 @@ To enforce a ratio between validator losses and loss to protocol utility, we set
\begin{equation}
\BP(\totaldeposit, \epoch - \epochLF) \equiv \frac{k_1}{\totaldeposit^p} + k_2 * \lfloor \log_2(\epoch - \epochLF) \rfloor\; .
\end{equation}
\TODO{what is $p$ in the in the above equation?}
\todo{what is $p$ in the in the above equation?}
The first term serves to take profits for non-committers away; the second term creates a penalty which is proportional to the loss in protocol utility.
@ -338,7 +304,7 @@ We define the degree that malicious validators can create penalties for honest v
\begin{equation}
\GF{ \gamesymbol,C } \equiv \max_{S \in strategies(T \setminus C)} \frac{loss(C) }{\min[ 0, loss(Players \setminus C) ] } \; .
\end{equation}
\TODO{I need to work on this equation more. I don't like it yet.}
\todo{I need to work on this equation more. I don't like it yet.}
@ -359,9 +325,9 @@ A strategy that imposes a loss to outsiders either at no cost to a coalition, or
\label{fig:GF}
\end{figure}
Then to define the griefing factor over the entire game, we sum the area under the curve in \Figref{fig:GF} leading to,
Then to define the griefing factor over the entire game, we sum the area under the curve in \figref{fig:GF} leading to,
\begin{equation}
\GF{ \gamesymbol } \equiv \int_{0}^{1} \mathscr{GF}( \gamesymbol, \alpha ) \; d\alpha \; .
\GF{ \gamesymbol } \equiv \int_{0}^{1} GF( \gamesymbol, \alpha ) \; d\alpha \; .
\end{equation}
@ -384,14 +350,11 @@ Let us now analyze the attack types:
\centering
\renewcommand{\arraystretch}{2}
\begin{tabular}{l l l }
\toprule
\thead{Attack} & \thead{Amount lost by \\ malicious validators} & \thead{Amount lost by \\ honest validators} \\
\midrule
\textbf{Attack} & \textbf{Amount lost by malicious validators} & \textbf{Amount lost by honest validators} \\
Minority of size $\alpha < \frac{1}{2}$ non-Prepares & $\NPP * \alpha + \NPCP(\alpha) * \alpha$ & $\NPCP(\alpha) * (1-\alpha)$ \\
Majority censors $\alpha < \frac{1}{2}$ Prepares & $\NPCP(\alpha) * (1-\alpha)$ & $\NPP * \alpha + \NPCP(\alpha) * \alpha$ \\
Minority of size $\alpha < \frac{1}{2}$ non-Commits & $\NCP * \alpha + \NCCP(\alpha) * \alpha$ & $\NCCP(\alpha) * (1-\alpha)$ \\
Majority censors $\alpha < \frac{1}{2}$ Commits & $\NCCP(\alpha) * (1-\alpha)$ & $\NCP * \alpha + \NCCP(\alpha) * \alpha$ \\
\bottomrule
\end{tabular}
\caption{Attacks on the protocols and their costs to malicious validators and honest validators.}
\end{table}
@ -404,8 +367,8 @@ There is a symmetry between the non-Prepare case and the non-Commit case, so we
\begin{figure}[h!bt]
\centering
\subfloat[Utility with function of $p$]{ \includegraphics[width=3in]{goodness-with-p.pdf} \label{fig:utility} }
\subfloat[\NCCP and \NPCP as a function of $\alpha$]{ \includegraphics[width=3in]{cs.pdf} \label{fig:collectivepenalties} }
Utility with function of $p${ \includegraphics[width=3in]{goodness-with-p.pdf} \label{fig:utility} }
\NCCP and \NPCP as a function of $\alpha${ \includegraphics[width=3in]{cs.pdf} \label{fig:collectivepenalties} }
\caption{Plotting the griefing factor as a function of the proportion of players coordinating to grief.}
\label{fig:GF}
@ -417,7 +380,7 @@ In the normal case, anything less than $\frac{1}{3}$ Commits provides no economi
Now, let us analyze the griefing factors, to try to determine an optimal shape for $\NCCP$. The griefing factor for non-Committing is,
\begin{equation}
\mathscr{GF} = \frac{(1-\alpha) * \NCCP(\alpha)}{\alpha * (1 + \NCCP(\alpha))} \; .
GF = \frac{(1-\alpha) * \NCCP(\alpha)}{\alpha * (1 + \NCCP(\alpha))} \; .
\end{equation}
The griefing factor for censoring is the inverse of this. If we want the griefing factor for non-Committing to equal one, then we could compute: