From bc06b2fd68379020c6aeac9fe55282638f4b5bbb Mon Sep 17 00:00:00 2001 From: Virgil Griffith Date: Wed, 23 Aug 2017 22:09:05 +0800 Subject: [PATCH] Add files via upload --- casper4/papers/casper-economics/appendix.tex | 22 +- .../casper_economics_basic.tex | 235 ++++++++++++------ .../papers/casper-economics/eth_header.tex | 25 +- casper4/papers/casper-economics/ethereum.bib | 37 +++ 4 files changed, 239 insertions(+), 80 deletions(-) diff --git a/casper4/papers/casper-economics/appendix.tex b/casper4/papers/casper-economics/appendix.tex index 7bee800..700a114 100644 --- a/casper4/papers/casper-economics/appendix.tex +++ b/casper4/papers/casper-economics/appendix.tex @@ -1,10 +1,30 @@ - +\appendix \clearpage \part*{Appendix} +\section{Safety Failure} +\label{app:safetyfailure} +\TODO{Put the full description/definition of conflicting blocks here.} + + + + \section{Unused text} \todo{This is where text goes that for which a home hasn't been found yet. If no home is found, it will be deleted.} Two other reasons to participate in stake pools are (i) to mitigate \emph{key theft risk} (i.e. an attacker hacking into their online machine and stealing the key), and (ii) to mitigate \emph{liveness risk}, the possibility that the validator node will go offline, perhaps because the operator does not have the time to manage a high-uptime setup. + +\todo{Do we want to require that the Prepare be done in the first 1/2 of the epoch? I'm mildly concerned there may not always be enough time to Commit.} + +\todo{Remember: The only block you're allowed to Prepare is the last block of each epoch.} + +\todo{Remember: Even if the Finalization goes through, the collective penalties are still applied.} + + +\textbf{Questions} +\begin{itemize} +\item It's unclear to me why we need $\epochsource$ in the Prepare. + +\end{itemize} diff --git a/casper4/papers/casper-economics/casper_economics_basic.tex b/casper4/papers/casper-economics/casper_economics_basic.tex index 115da60..433527f 100644 --- a/casper4/papers/casper-economics/casper_economics_basic.tex +++ b/casper4/papers/casper-economics/casper_economics_basic.tex @@ -51,6 +51,7 @@ \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} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -67,8 +68,16 @@ We give an introduction to the incentives in the Casper the Friendly Finality Ga \section{Introduction} -\todo{define blocks, epochs} +\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} +\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: @@ -82,7 +91,7 @@ In the Casper protocol, there is a set of validators, and in each epoch validato \epoch & the current epoch \\ $\hashsource$ & the most recent justified hash \\ $\epochsource$ & the epoch containing hash $\hashsource$ \\ - \signature & signature from the validator's private key \\ + \signature & signature from the validator's private key of the tuplet $(\hash,\epoch,\hashsource,\epochsource)$. \\ \bottomrule \end{tabular} \label{tbl:prepare} } @@ -95,7 +104,7 @@ In the Casper protocol, there is a set of validators, and in each epoch validato \bottomrule \end{tabular} \label{tbl:commit} } - \caption{The schematic of the \msgPREPARE and \msgCOMMIT messages. \todo{it's unclear to me why we need $\epochsource$.}} + \caption{The schematic of the \msgPREPARE and \msgCOMMIT messages.} \label{fig:messages} \end{table} @@ -105,14 +114,16 @@ Each validator has a \emph{deposit size}; when a validator joins their deposit s 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 \begin{equation} -[\msgPREPARE, \epoch, \hash, \epochsource, \hashsource, \signature] +\langle \msgPREPARE, \epoch, \hash, \epochsource, \hashsource, \signature \rangle \label{eq:msgPREPARE} \end{equation} -for some specific $\epochsource$ and $\hashsource$. A hash converts from justified to \emph{finalized}, if $\nicefrac{2}{3}$ Commits +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} -[\msgCOMMIT, \epoch, \hash, \signature] \; , +\langle \msgCOMMIT, \epoch, \hash, \signature \rangle \; , \label{eq:msgCOMMIT} \end{equation} @@ -121,45 +132,71 @@ for the same \epoch and \hash as in \eqref{eq:msgPREPARE}. The $\hash$ is the b Possible deviations from this ideal execution that we want to minimize or avoid include: \begin{itemize} -\item Violating any of the four slashing conditions. \cite{minslashing} +\item Violating any of the two Casper Commandments. \cite{minslashing} To violate either Commandment is to forfeit one's \emph{entire deposit}. + \begin{enumerate} - \item \textbf{\textsc{prepare\_req}}. If a validator Prepares specifying a the $\hashsource$ is not \emph{justified}, the validator is penalized. + \item[\textbf{I.}] \textsc{A validator shalt not publish two nonidentical Prepares with the same $\epoch$ value.} + + This is equivalent to that each validator may Prepare to exactly one (\hash, \epochsource, \hashsource) triplet per epoch. - \item \textbf{\textsc{no\_dbl\_prepare}}. If a validator publishes two nonidentical Prepares with the same $\epoch$ value, the validator is penalized. This is equivalent to that each validator may Prepare to exactly one (\hash, \epochsource, \hashsource) triplet per epoch. + \item[\textbf{IIa.}] \textsc{A validator shalt not publish an Commit between a Prepare jump.} + + Equivalently, a validator will not publish - \item \textbf{\textsc{commit\_req}}. If a validator Commits an unjustified hash, the validator's is penalized. - \item \textbf{\textsc{prepare\_commit\_consistency}}. Given a Prepare-Commit pair of a single hash, from a single validator of the form, +% \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*} -[\msgPREPARE, \epoch_1, \hash, \epochsource, \hashsource, \signature] +\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*} +where the epochs satisfy $\epochsource < \epoch_c < \epoch_p$. + + + \item[\textbf{IIb.}] \textsc{A validator shall only publish compatible Prepare/Commit pairings.} + + Equivalently, for a single hash $\hash$, a validator shall only 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*} -[\msgCOMMIT, \epoch_2, \hash, \signature] \;, -\label{eq:msgCOMMIT} +\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 epochs must satisfy $\epochsource < \epoch_1 < \epoch_2$. Otherwise, the validator is penalized. - -\end{enumerate} +where the epochs satisfy $\epochsource < \epoch_p \leq \epoch_c$. + + + +% \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 yet finalized. + +\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 hash, $\hashLJ$, and only reward Prepares whose $\epochsource$ and $\hashsource = \hashLJ$. These two techniques will help to coordinate validators toward Preparing and Committing a single hash \hash with a single source \hashsource. +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. \section{Rewards and Penalties} -We define the following nonnegative functions, +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$: \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. @@ -173,29 +210,27 @@ We define the following nonnegative functions, We also define the following nonnegative constants: \begin{itemize} - \item $\NPP$ (``non-prepare penalty''): the penalty for not preparing. $\NPP > 0$. - \item $\NCP$ (``non-commit penalty''): the penalty for not committing, if there was a justified hash which the validator \emph{could} have Committed. \NCP is a constant and $\NCP > 0$. + \item $\NPP$ (``non-prepare penalty''): the penalty for not Preparing any block during the epoch. \todo{correct?} + \item $\NCP$ (``non-commit penalty''): the penalty for not Committing any block during the epoch, if there was a justified hash which the validator \emph{could} have Committed. \todo{correct?} \end{itemize} -All functions return a nonnegative scalar with no units. Technically these values can exceed 1.0, but in practice they will be rarely exceed $0.01$. +Note that a validator publishing a Prepare/Commit doesn't entail escaping a \NPP/\NCP; it could be the case that either because of high network latency or a malicious majority censorship attack, the Prepares and Commits are not included into the blockchain in time and so the incentivization mechanism does not see them. Likewise, for $\NPCP$ and $\NCCP$, the $\alpha$ input is the proportion of validators whose Prepares and Commits are \emph{not visible}, not the proportion of validators who \emph{tried to send} a Prepare/Commit. -Note that a validator Preparing/Committing it won't incur a \NPP/\NCP; it could be the case that either because of very high network latency or a malicious majority censorship attack, the Prepares and Commits are not included into the blockchain in time and so the incentivization mechanism does not see them. For $\NPCP$ and $\NCCP$ similarly, the $\alpha$ input is the proportion of validators whose Prepares and Commits are \emph{not visible}, not the proportion of validators who \emph{tried to send} Prepares/Commits. +When we talk about Preparing and Committing the ``correct value'', we are referring to the hash \hash and the parent epoch $\epochsource$ and parent hash $\hashsource$. -When we talk about preparing and committing the ``correct value'', we are referring to the hash \hash and the parent epoch $\epochsource$ and parent hash $\hashsource$. +We define the following reward and penalty schedule. This is the procedure for rewards and penalties, and is the entirety of the incentivization structure. It runs at the \emph{end} of every epoch: + \begin{enumerate} + \item All validators get a reward of $\BIR(\totaldeposit)$ (e.g., if $\BIR(\totaldeposit) = 0.0002$ then a validator with $10,000$ coins deposited gets a per-epoch reward of $2$ coins) + \item If the protocol does not see a Prepare from a given validator during the epoch, the validator is penalized $\BP(\totaldeposit, \epoch - \epochLF) * \NPP$ \todo{how does the incentive mechanism know \epoch?} + \item If the protocol does not see a Commit from a given validator during the epoch, and a block was justified (so a Commit \emph{could have} been seen), the validator is penalized $\BP(\totaldeposit, \epoch - \epochLF) * \NCP$. + \item If the protocol saw Prepares from proportion $p$ validators during the epoch, then \emph{every} validator is penalized $\BP(\totaldeposit, \epoch - \epochLF) * \NPCP(1 - p)$. + \item If the protocol saw Commits from proportion $p$ validators during the epoch, and a block was justified (so validators \emph{could have} Commited), then \emph{every} validator is penalized $\BP(\totaldeposit, \epoch - \epochLF) * \NCCP(1 - p)$. + \item The blockchain's recorded \epochLF and \hashLF are updated to the latest values. \todo{correct?} + \end{enumerate} -We now define the following reward and penalty schedule, which runs at the \emph{end} of each epoch. -\begin{enumerate} -\item All validators get a reward of $\BIR(\totaldeposit)$ (e.g., if $\BIR(\totaldeposit) = 0.0002$ then a validator with $10,000$ coins deposited gets a per-epoch reward of $2$ coins) -\item If the protocol does not see a Prepare from a given validator during the epoch, the validator is penalized $\BP(\totaldeposit, \epoch - \epochLF) * \NPP$ -\item If the protocol does not see a Commit from a given validator during the epoch, and a Prepare was justified so a Commit \emph{could have} been seen, they are penalized $\BP(\totaldeposit, \epoch - \epochLF) * \NCP$. -\item If the protocol saw Prepares from proportion $p$ validators during the epoch, \emph{every} validator is penalized $\BP(\totaldeposit, \epoch - \epochLF) * \NPCP(1 - p)$ -\item If the protocol saw Commits from proportion $p$ validators during the epoch, and a Prepare was justified so a validator \emph{could have} Commited, then \emph{every} validator is penalized $\BP(\totaldeposit, \epoch - \epochLF) * \NCCP(1 - p)$. -\item The blockchain's recorded \epochLF and \hashLF are updated to the latest values. \todo{correct?} -\end{enumerate} -This is the entirety of the incentivization structure. We will define the functions and constants later, attempting to derive the specific values from first principles and desired objectives. \section{Three theorems} @@ -203,17 +238,17 @@ We seek to prove the following: \begin{theorem}[\todo{First theorem}] \label{theorem1} -If no validator has more than $\frac{1}{3}$ of the total deposit, i.e., $\max_i(D) \leq \frac{\totaldeposit}{3}$, then Preparing the last blockhash of each epoch and Committing the $\hashLJ$ is a Nash equilibrium. (Section \ref{sect:indivchoice}) +If no validator has more than $\frac{1}{3}$ of the total deposit, i.e., $\max_i(D) \leq \frac{\totaldeposit}{3}$, then Preparing the last blockhash of the previous epoch and then Committing that hash is a Nash equilibrium. (Section \ref{sect:indivchoice}) \end{theorem} \begin{theorem}[\todo{Second theorem}] \label{theorem2} -Even if all validators collude, the ratio between the harm inflicted and the penalties paid by validators is bounded above by some constant. Note that this requires a measure of ``harm inflicted''; we discuss this Section \ref{sect:collectivechoice}. +Even if all validators collude, the ratio of the harm inflicted on the network and the penalties paid by the colluding validators is upperbounded by some constant. (Section \ref{sect:collectivechoice}) Note that this requires a measure of ``harm inflicted''. \end{theorem} \begin{theorem}[\todo{Third theorem}] \label{theorem3} -The \emph{griefing factor}, the ratio of the penalty incurred by the victims of an attack and penalty incurred by the attackers. Even when the attackers hold a majority of the total deposit, the griefing factor is at most 2. (Section \ref{sect:griefingfactor}) +Even when the attackers hold a majority of the total deposit, the ratio of the penalty incurred by the victims of an attack and penalty incurred by the attackers, or \emph{griefing factor}, is at most 2. (Section \ref{sect:griefingfactor}) \end{theorem} \subsection{Individual choice analysis} @@ -221,21 +256,42 @@ The \emph{griefing factor}, the ratio of the penalty incurred by the victims of The individual choice analysis is simple. Suppose that during epoch $\epoch$ the proposal mechanism Prepares a hash $\hash$ and the Casper incentivization mechanism specifies some $\epochsource$ and $\hashsource$. Because, as per definition of the Nash equilibrium, we are assuming that all validators except for the validator that we are analyzing are following the equilibrium strategy, we know that $\ge \frac{2}{3}$ of validators Prepared in the last epoch and so $\epochsource = \epoch - 1$, and $\hashsource$ is the direct parent of $\hash$. -Hence, the PREPARE\_COMMIT\_CONSISTENCY slashing condition poses no barrier to preparing $(\epoch, \hash, \epochsource, \hashsource)$. Since, in epoch \epoch, we are assuming that all other validators \emph{will} Prepare these values and then Commit \hash, we know \hash will be a hash in the main chain, and so a validator will pay a penalty if they do not Prepare $(\epoch, \hash, \epochsource, \hashsource)$, and they can avoid the penalty if they do Prepare these values. +Hence, the PREPARE\_COMMIT\_CONSISTENCY slashing condition poses no barrier to Preparing $(\epoch, \hash, \epochsource, \hashsource)$. Since, in epoch \epoch, we are assuming that all other validators \emph{will} Prepare these values and then Commit \hash, we know \hash will be a hash in the main chain, and so a validator will pay a penalty if they do not Prepare $(\epoch, \hash, \epochsource, \hashsource)$, and they can avoid the penalty if they do Prepare these values. We are assuming there are $\frac{2}{3}$ Prepares for $(\epoch, \hash, \epochsource, \hashsource)$, and so \textsc{prepare\_req} also poses no barrier to committing \hash. Committing \hash allows a validator to avoid \NCP. Hence, there is an economic incentive to Commit \hash. This shows that, if the proposal mechanism succeeds at presenting to validators a single primary choice, Preparing and Committing the value selected by the proposal mechanism is a Nash equilibrium. -\todo{Put two 2x2 tables here for the trade-offs in Preparing and Committing \hash?} + +\begin{table}[h!bt] + \centering + + \subfloat[Preparing $\langle \epoch, \hash, \epochsource, \hashsource \rangle$ ]{ \begin{tabular}{l c} \toprule + \thead{Action} & \thead{Payoff} \\ + \midrule + 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 + Commiting & 0 \\ + Not Commiting & $-\NCP - \NCCP(\alpha)$ \\ + \bottomrule + \end{tabular} + \label{tbl:commit} } + \caption{Payoffs for ideal individual behaviors.} + \label{fig:individualpayoffs} +\end{table} + \subsection{Collective choice model} \label{sect:collectivechoice} -To model the protocol in a collective-choice context, we first define a \emph{protocol utility function}. The protocol utility function quantifies ``how well the protocol execution is doing''. Although our specific protocol utility function cannot be derived from first principles, we can intuitively justify it. - -We define our protocol utility function as, +To model the protocol in a collective-choice context, we first define a \emph{protocol utility function}. The protocol utility function quantifies ``how well the protocol execution is doing''. Although our specific protocol utility function cannot be derived from first principles, we can intuitively justify it. We define our protocol utility function as, \begin{equation} -U = \sum_{k = 0}^{\epoch} - \log_2\left[ k - \epochLF \right] - M F \; . +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} Where: @@ -244,17 +300,20 @@ Where: \item $\epoch$ is the current epoch, starting from $0$. \item $\epochLF$ is the index of the last finalized epoch. \todo{To be clear, does the \epochLF change with the term $k$, or is it fixed?} \item $M$ is a very large constant. -\item $F$ is an Indicator function. It returns $1$ if a safety failure has taken place, otherwise 0. \todo{It'd be nice to get a descripton of the conditions that lead to a ``safety failure''.} +\item $F$ is an Indicator Function. It returns $1$ if a safety failure has taken place, otherwise 0. A safety failure is defined as the mechanism finalizing two conflicting blocks. This is discussed in Apppendix \ref{app:safetyfailure} \end{itemize} The second term in the function is easy to justify: safety failures are very bad. The first term is trickier. To see how the first term works, consider the case where every epoch such that $\epoch$ mod $N$, for some $N$, is zero is finalized and other epochs are not. The average total over each $N$-epoch slice will be roughly $\sum_{i=1}^N -\log_2(i) \approx N * \left[ \log_2(N) - \frac{1}{\ln(2)} \right]$. Hence, the utility per block will be roughly $-\log_2(N)$. This basically states that a blockchain with some finality time $N$ has utility roughly $-\log(N)$, or in other words \emph{increasing the finality time of a blockchain by a constant factor causes a constant loss of utility}. The utility difference between 1 minute and 2 minute finality is the same as the utility difference between 1 hour and 2 hour finality. -This can be justified in two ways. First, one can intuitively argue that a user's psychological discomfort of waiting for finality roughly matches a logarithmic schedule. At the very least, the difference between 3600 sec and 3610 sec finality feels much more negligible than the difference between 1 sec and 11 sec finality, and so the claim that the difference between 10 sec and 20 sec finality is similar to the difference between 1 hour finality and 2 hour finality does not seem farfetched. \footnote{One can look at various blockchain use cases, and see that they are roughly logarithmically uniformly distributed along the range of finality times between around 200 miliseconds (``Starcraft on the blockchain'') and one week (land registries and the like). \todo{add a citation for this or delete.}} +This can be justified in two ways. First, one can intuitively argue that a user's psychological discomfort of waiting for finality roughly matches a logarithmic schedule. At the very least, the difference between 3600 sec and 3610 sec finality feels much more negligible than the difference between 1 sec and 11 sec finality, and so the claim that the difference between 10 sec and 20 sec finality is similar to the difference between 1 hour finality and 2 hour finality seems reasonable.\footnote{One can look at various blockchain use cases, and see that they are roughly logarithmically uniformly distributed along the range of finality times between around 200 miliseconds (``Starcraft on the blockchain'') and one week (land registries and the like). \todo{add a citation for this or delete.}} -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, and (ii) prevent finality by having $> \frac{1}{3}$ \todo{$\ge or >$?} of validators not Prepare or Commit to the same hash. Causing a safety failure violates one of the slashing conditions and thus ensures a large 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, +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} -\min \left[ \NPP * \frac{1}{3} + \NPCP\left(\frac{1}{3}\right), \NCP * \frac{1}{3} + \NCCP\left(\frac{1}{3}\right) \right] * \BP(\totaldeposit, \epoch - \epochLF) \; . +\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} \end{equation} To enforce a ratio between validator losses and loss to protocol utility, we set, @@ -266,16 +325,18 @@ To enforce a ratio between validator losses and loss to protocol utility, we set 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. -This connection between validator losses and loss to protocol utility has several consequences. First, it establishes that harming the protocolexecution is costly, and harming the protocol execution more costs more. Second, it establishes that the protocol approximates the properties of a \emph\emph{potential game} [cite]. Potential games have the property that Nash equilibria of the game correspond to local maxima of the potential function (in this case, protocol utility), and so correctly following the protocol is a Nash equilibrium even in cases where a coalition has more than $\frac{1}{3}$ of the total validators. Here, the protocol utility function is not a perfect potential function, as it does not always take into account changes in the \emph{quantity} of prepares and commits whereas validator rewards do, but it does come close. +This connection between validator losses and loss to protocol utility has several consequences. First, it establishes that harming the protocolexecution is always a net loss, with the net loss increasing with the harm inflicted. Second, it establishes that the protocol approximates the properties of a \emph{game} \cite{monderer1996potential}. Potential games have the property that Nash equilibria of the game correspond to local maxima of the potential function (in this case, protocol utility), and so correctly following the protocol is a Nash equilibrium even in cases where attackers control $>\frac{1}{3}$ of the total deposit. + +Here, the protocol utility function is not a perfect potential function, as it does not always take into account changes in the \emph{quantity} of Prepares and Commits whereas validator rewards do, but it does come close. \todo{Could someone do better than our \eqref{eq:utilityfunction}?} \subsection{Griefing factor analysis} \label{sect:griefingfactor} -Griefing factor analysis is important because it provides a way to quanitfy the risk to honest validators. In general, if all validators are honest, and if network latency stays below half \todo{half, right?} the length of an epoch, then validators face zero penalties to their respective deposits. In the case where malicious validators exist, however, they can interfere in the protocol in ways that penalize themselves as well as honest validators. +Griefing factor analysis quanitfies the risk to honest validators. In general, if all validators are honest, and if network latency stays below half \todo{half, right?} the time of an epoch, then they face zero penalties. In the case where malicious validators exist, however, they can create penalties for themselves as well as honest validators. -We define the ``griefing factor'' as, +We define the degree that malicious validators can create penalties for honest validators relative to their own penalties as the ``griefing factor'' of a game. We define this as, \begin{equation} -\mathscr{GF}(\gamesymbol,C) \equiv \max_{S \in strategies(T \setminus C)} \frac{loss(C) }{\min[ 0, loss(Players \setminus C) ] } \; . +\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.} @@ -298,46 +359,68 @@ 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, +\begin{equation} +\GF{ \gamesymbol } \equiv \int_{0}^{1} \mathscr{GF}( \gamesymbol, \alpha ) \; d\alpha \; . +\end{equation} + + Let us start off our griefing analysis by not taking into account validator churn, so the validator set is always the same. In Casper, we can identify the following deviating strategies: \begin{enumerate} -\item A minority of validators do not prepare, or Prepare incorrect values. -\item (Mirror image of 1) A censorship attack where a majority of validators does not accept prepares from a minority of validators (or other isomorphic attacks such as waiting for the minority to Prepare hash $H_1$ and then preparing $H_2$, making $H_2$ the dominant chain and denying the victims their rewards). +\item A minority of validators do not Prepare, or Prepare incorrect values. +\item (Mirror image of 1) A censorship attack where a majority of validators does not accept Prepares from a minority of validators (or other isomorphic attacks such as waiting for the minority to Prepare hash $H_1$ and then preparing $H_2$, making $H_2$ the dominant chain and denying the victims their rewards). \item A minority of validators do not commit. \item (Mirror image of 3) A censorship attack where a majority of validators does not accept commits from a minority of validators. \end{enumerate} -Notice that, from the point of view of griefing factor analysis, it is immaterial whether or not any hash in a given epoch was justified or finalized. The Casper mechanism only pays attention to finalization in order to calculate $\BP(D, \epoch, \epochLF)$, the penalty scaling factor. This value scales penalties evenly for all participants, so it does not affect griefing factors. +Notice that, from the point of view of griefing factor analysis, it is immaterial whether or not any hash in a given epoch was justified or finalized. The Casper mechanism only pays attention to finalization in order to calculate $\BP(D, \epoch - \epochLF)$, the penalty scaling factor. This value scales penalties evenly for all participants, so it does not affect griefing factors. Let us now analyze the attack types: \begin{table} -\renewcommand{\arraystretch}{2} -\begin{tabular}{l l l } -\toprule -\textbf{Attack} & \textbf{Amount lost by attacker} & \textbf{Amount lost by victims} \\ -\midrule -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} +\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 + 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} -In general, we see a perfect symmetry between the non-Commit case and the non-Prepare case, so we can assume $\frac{\NCCP(\alpha)}{\NCP} = \frac{\NPCP(\alpha)}{\NPP}$. Also, from a protocol utility standpoint, we can make the observation that seeing $\frac{1}{3} \le p_c < \nicefrac{2}{3}$ commits is better than seeing fewer commits, as it gives at least some economic security against finality reversions, so we want to reward this scenario more than the scenario where we get $\frac{1}{3} \le p_c < \nicefrac{2}{3}$ prepares. Another way to view the situation is to observe that $\frac{1}{3}$ non-prepares causes \emph{everyone} to non-commit, so it should be treated with equal severity. +\subsection{Shape of the penalities} +There is a symmetry between the non-Prepare case and the non-Commit case, so we assume $\frac{\NCCP(\alpha)}{\NCP} = \frac{\NPCP(\alpha)}{\NPP}$. Also, from a protocol utility standpoint (\ref{fig:utility}), increasing Commits are always useful as long as $p > \frac{1}{3}$, as it gives at least some economic security against finality reversions. However, Prepares $< \frac{2}{3}$ is exceedingly harmful as is it prevents \emph{any} Commits. -In the normal case, anything less than $\frac{1}{3}$ commits provides no economic security, so we can treat $p_c < \frac{1}{3}$ commits as equivalent to no commits; this thus suggests $\NPP = 2 * \NCP$. We can also normalize $\NCP = 1$. -Now, let us analyze the griefing factors, to try to determine an optimal shape for $\NCCP$. The griefing factor for non-committing is, + +\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} } + + \caption{Plotting the griefing factor as a function of the proportion of players coordinating to grief.} + \label{fig:GF} +\end{figure} + + +In the normal case, anything less than $\frac{1}{3}$ Commits provides no economic security, so we can treat $p_c < \frac{1}{3}$ Commits as equivalent to no Commits; this thus suggests $\NPP = 2 * \NCP$. We can also normalize $\NCP = 1$. + +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))} \; . \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: +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: \begin{eqnarray} \alpha * (1 + \NCCP(\alpha)) &=& (1-\alpha) * \NCCP(\alpha) \\ @@ -346,11 +429,11 @@ The griefing factor for censoring is the inverse of this. If we want the griefin \NCCP(\alpha) &=& \frac{\alpha}{1-2\alpha} \end{eqnarray} -Note that for $\alpha = \frac{1}{2}$, this would set the \NCCP to infinity. Hence, with this design a griefing factor of $1$ is infeasible. We \emph{can} achieve that effect in a different way - by making \NCP itself a function of $\alpha$; in this case, $\NCCP = 1$ and $\NCP = \max[0, 1 - 2 * \alpha]$ would achieve the desired effect. If we want to keep the formula for \NCP constant, and the formula for \NCCP reasonably simple and bounded, then one alternative is to set $\NCCP(\alpha) = \frac{\alpha}{1-\alpha}$; this keeps griefing factors bounded between $\frac{1}{2}$ and $2$. +Note that for $\alpha = \frac{1}{2}$, this would set the \NCCP to infinity. Hence, with this design a griefing factor of $1$ is infeasible. We \emph{can} achieve that effect in a different way - by making \NCP itself a function of $\alpha$; in this case, $\NCCP = 1$ and $\NCP = \max[0, 1 - 2\alpha]$ would achieve the desired effect. If we want to keep the formula for \NCP constant, and the formula for \NCCP reasonably simple and bounded, then one alternative is to set $\NCCP(\alpha) = \frac{\alpha}{1-\alpha}$; this keeps griefing factors bounded between $\frac{1}{2}$ and $2$. \section{Pools} -In a traditional (ie. not sharded or otherwise scalable) blockchain, there is a limit to the number of validators that can be supported, because each validator imposes a substantial amount of overhead on the system. If we accept a maximum overhead of two consensus messages per second, and an epoch time of 1400 seconds, then this means that the system can handle 1400 validators (not 2800 because we need to count prepares and commits). Given that the number of individual users interested in staking will likely exceed 1400, this necessarily means that most users will participate through some kind of ``stake pool''. +In a traditional (i.e., not sharded or otherwise scalable) blockchain, there is a limit to the number of validators that can be supported, because each validator imposes a substantial amount of overhead on the system. If we accept a maximum overhead of two consensus messages per second, and an epoch time of 1400 seconds, then this means that the system can handle 1400 validators (not 2800 because we need to count prepares and commits). Given that the number of individual users interested in staking will likely exceed 1400, this necessarily means that most users will participate through some kind of ``stake pool''. There are several possible kinds of stake pools: @@ -370,17 +453,15 @@ We expect pools of different types to emerge to accomodate smaller users. In the The above analysis gives a parametrized scheme for incentivizing in Casper, and shows that it is a Nash equilibrium in an uncoordinated-choice model with a wide variety of settings. We then attempt to derive one possible set of specific values for the various parameters by starting from desired objectives, and choosing values that best meet the desired objectives. This analysis does not include non-economic attacks, as those are covered by other materials, and does not cover more advanced economic attacks, including extortion and discouragement attacks. We hope to see more research in these areas, as well as in the abstract theory of what considerations should be taken into account when designing reward and penalty schedules. -\textbf{Future Work.} \todo{fill me in} +\textbf{Future Work.} We would like to see a better protocol utility function \eqref{eq:utilityfunction}. \todo{fill me in} \textbf{Acknowledgements.} We thank Virgil Griffith for review. -\section{References} +%\section{References} \bibliographystyle{abbrv} \bibliography{ethereum} -Optimal selfish mining strategies in Bitcoin; Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar: https://arxiv.org/pdf/1507.06183.pdf - -Potential games; Dov Monderer and Lloyd Shapley: \url{http://econpapers.repec.org/article/eeegamebe/v\_3a14\_3ay\_3a1996\_3ai\_3a1\_3ap\_3a124-143.htm} \input{appendix.tex} \end{document} + \ No newline at end of file diff --git a/casper4/papers/casper-economics/eth_header.tex b/casper4/papers/casper-economics/eth_header.tex index 0c5c0b6..edccf52 100644 --- a/casper4/papers/casper-economics/eth_header.tex +++ b/casper4/papers/casper-economics/eth_header.tex @@ -37,6 +37,21 @@ % for indicator functions \usepackage{dsfont} +% For automatic capitalizaton of section names, etc. +\usepackage{titlesec,titlecaps} + + +\Addlcwords{is with of the and in} +%\Addlcwords{of the} +%\Addlcwords{and} +\titleformat{\section}[block]{}{\normalfont\Large\bfseries\thesection.\;}{0pt}{\formatsectiontitle} +\newcommand{\formatsectiontitle}[1]{\normalfont\Large\bfseries\titlecap{#1}} + +\titleformat{\subsection}[block]{}{\normalfont\large\bfseries\thesubsection.\;}{0pt}{\formatsubsectiontitle} +\newcommand{\formatsubsectiontitle}[1]{\normalfont\large\bfseries\titlecap{#1}} + + + % for pretty Euler script @@ -86,15 +101,21 @@ % will do the rest. \newcommand{\tblref}[1]{Table~\ref{#1}} %\renewcommand*{\figref}[1]{Fig.~\ref{#1}} -\newcommand{\equref}[1]{(\ref{#1})} +\renewcommand{\eqref}[1]{eq.~\ref{#1}} -\newcommand{\Tblref}[1]{Table~\ref{#1}} + +\newcommand{\figref}[1]{Figure~\ref{#1}} \newcommand{\Figref}[1]{Figure~\ref{#1}} \newtheorem{theorem}{Theorem} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% for better manipulation of tables +\usepackage{makecell} +\renewcommand\theadfont{\bfseries} + + %----------------------------------------------------------------------------- % Misc symbols that I like %----------------------------------------------------------------------------- diff --git a/casper4/papers/casper-economics/ethereum.bib b/casper4/papers/casper-economics/ethereum.bib index f5588ee..305a18d 100644 --- a/casper4/papers/casper-economics/ethereum.bib +++ b/casper4/papers/casper-economics/ethereum.bib @@ -6,6 +6,43 @@ %% Saved with string encoding Unicode (UTF-8) + +@article{monderer1996potential, + title={Potential games}, + author={Monderer, Dov and Shapley, Lloyd S}, + journal={Games and economic behavior}, + volume={14}, + number={1}, + pages={124--143}, + year={1996}, + publisher={Elsevier} +} + +@misc{vasin2014blackcoin, + title={Blackcoin’s proof-of-stake protocol v2}, + author={Vasin, Pavel}, + year={2014}, + publisher={Tech. rep. URL: http://blackcoin. co/blackcoin-pos-protocol-v2-whitepaper. pdf} +} + +@article{king2012ppcoin, + title={Ppcoin: Peer-to-peer crypto-currency with proof-of-stake}, + author={King, Sunny and Nadal, Scott}, + journal={self-published paper, August}, + volume={19}, + year={2012} +} + +@inproceedings{bentov2016pos, + title={Cryptocurrencies without proof of work}, + author={Bentov, Iddo and Gabizon, Ariel and Mizrahi, Alex}, + booktitle={International Conference on Financial Cryptography and Data Security}, + pages={142--157}, + year={2016}, + organization={Springer} +} + + @inproceedings{selfishminingBTC, title={Optimal selfish mining strategies in bitcoin}, author={Sapirshtein, Ayelet and Sompolinsky, Yonatan and Zohar, Aviv},