Updated papers more
This commit is contained in:
Vitalik Buterin
parent
28b6d42fae
commit
0d71921ef8
|
|
@ -1,13 +1,11 @@
|
||||||
\relax
|
\relax
|
||||||
\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction, Protocol I}{1}}
|
\@writefile{toc}{\contentsline {section}{\numberline {1}Principles}{1}}
|
||||||
\@writefile{toc}{\contentsline {section}{\numberline {2}Proof Sketch of Safety and Plausible Liveness}{3}}
|
\@writefile{toc}{\contentsline {section}{\numberline {2}Introduction, Protocol I}{2}}
|
||||||
\@writefile{toc}{\contentsline {section}{\numberline {3}Dynamic Validator Sets}{4}}
|
\@writefile{toc}{\contentsline {section}{\numberline {3}Proof Sketch of Safety and Plausible Liveness}{4}}
|
||||||
\@writefile{toc}{\contentsline {section}{\numberline {4}Claims}{6}}
|
\@writefile{toc}{\contentsline {section}{\numberline {4}Fork Choice Rule}{5}}
|
||||||
\@writefile{toc}{\contentsline {section}{\numberline {5}Individual choice analysis}{6}}
|
\@writefile{toc}{\contentsline {section}{\numberline {5}Dynamic Validator Sets}{6}}
|
||||||
\@writefile{toc}{\contentsline {section}{\numberline {6}Collective choice model}{7}}
|
\@writefile{toc}{\contentsline {section}{\numberline {6}Mass Crash Failure Recovery}{7}}
|
||||||
\@writefile{toc}{\contentsline {section}{\numberline {7}Griefing factor analysis}{9}}
|
|
||||||
\@writefile{toc}{\contentsline {section}{\numberline {8}Pools}{11}}
|
|
||||||
\bibstyle{abbrv}
|
\bibstyle{abbrv}
|
||||||
\bibdata{main}
|
\bibdata{main}
|
||||||
\@writefile{toc}{\contentsline {section}{\numberline {9}Conclusions}{13}}
|
\@writefile{toc}{\contentsline {section}{\numberline {7}Conclusions}{8}}
|
||||||
\@writefile{toc}{\contentsline {section}{\numberline {10}References}{13}}
|
\@writefile{toc}{\contentsline {section}{\numberline {8}References}{8}}
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) (preloaded format=pdflatex 2017.6.27) 15 AUG 2017 04:11
|
This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) (preloaded format=pdflatex 2017.6.27) 15 AUG 2017 23:33
|
||||||
entering extended mode
|
entering extended mode
|
||||||
restricted \write18 enabled.
|
restricted \write18 enabled.
|
||||||
%&-line parsing enabled.
|
%&-line parsing enabled.
|
||||||
|
|
@ -158,82 +158,59 @@ LaTeX Font Info: External font `cmex10' loaded for size
|
||||||
LaTeX Font Info: External font `cmex10' loaded for size
|
LaTeX Font Info: External font `cmex10' loaded for size
|
||||||
(Font) <7> on input line 14.
|
(Font) <7> on input line 14.
|
||||||
LaTeX Font Info: External font `cmex10' loaded for size
|
LaTeX Font Info: External font `cmex10' loaded for size
|
||||||
(Font) <12> on input line 20.
|
(Font) <12> on input line 22.
|
||||||
LaTeX Font Info: External font `cmex10' loaded for size
|
LaTeX Font Info: External font `cmex10' loaded for size
|
||||||
(Font) <8> on input line 20.
|
(Font) <8> on input line 22.
|
||||||
LaTeX Font Info: External font `cmex10' loaded for size
|
LaTeX Font Info: External font `cmex10' loaded for size
|
||||||
(Font) <6> on input line 20.
|
(Font) <6> on input line 22.
|
||||||
LaTeX Font Info: Try loading font information for OMS+cmr on input line 25.
|
|
||||||
|
[1
|
||||||
|
|
||||||
|
{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}]
|
||||||
|
LaTeX Font Info: Try loading font information for OMS+cmr on input line 35.
|
||||||
|
|
||||||
(/usr/share/texlive/texmf-dist/tex/latex/base/omscmr.fd
|
(/usr/share/texlive/texmf-dist/tex/latex/base/omscmr.fd
|
||||||
File: omscmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
|
File: omscmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
|
||||||
)
|
)
|
||||||
LaTeX Font Info: Font shape `OMS/cmr/m/n' in size <12> not available
|
LaTeX Font Info: Font shape `OMS/cmr/m/n' in size <12> not available
|
||||||
(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 25.
|
(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 35.
|
||||||
[1
|
[2]
|
||||||
|
Overfull \hbox (1.48117pt too wide) in paragraph at lines 60--61
|
||||||
{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] [2]
|
|
||||||
Overfull \hbox (1.48117pt too wide) in paragraph at lines 50--51
|
|
||||||
[]\OT1/cmr/bx/n/12 NO[]DBL[]PREPARE\OT1/cmr/m/n/12 : a val-ida-tor can-not pre-
|
[]\OT1/cmr/bx/n/12 NO[]DBL[]PREPARE\OT1/cmr/m/n/12 : a val-ida-tor can-not pre-
|
||||||
pare two dif-fer-ent check-
|
pare two dif-fer-ent check-
|
||||||
[]
|
[]
|
||||||
|
|
||||||
[3] [4] [5]
|
[3] [4]
|
||||||
Overfull \hbox (10.7546pt too wide) in paragraph at lines 112--113
|
Overfull \hbox (48.00797pt too wide) in paragraph at lines 84--85
|
||||||
[]\OT1/cmr/m/n/12 Hence, the PRE-PARE[]COMMIT[]CONSISTENCY slash-ing con-di-tio
|
[]\OT1/cmr/m/n/12 [https://cdn-images-1.medium.com/max/800/1*IhXmzZG9toAs3oedZX
|
||||||
n poses
|
0spg.jpeg]
|
||||||
[]
|
[]
|
||||||
|
|
||||||
[6]
|
[5] [6] [7]
|
||||||
Overfull \hbox (5.39354pt too wide) in paragraph at lines 114--115
|
|
||||||
[]\OT1/cmr/m/n/12 We are as-sum-ing that there are $[]$ pre-pares for $(\OML/cm
|
|
||||||
m/m/it/12 e; H; epoch[]; hash[]\OT1/cmr/m/n/12 )$,
|
|
||||||
[]
|
|
||||||
|
|
||||||
[7]
|
|
||||||
Overfull \hbox (15.85455pt too wide) in paragraph at lines 137--137
|
|
||||||
[]\OT1/cmr/m/n/12 Now, we need to show that, for any given to-tal de-posit size
|
|
||||||
, $[]$
|
|
||||||
[]
|
|
||||||
|
|
||||||
[8] [9]
|
|
||||||
Underfull \hbox (badness 3291) in paragraph at lines 179--179
|
|
||||||
[]|\OT1/cmr/m/n/12 Amount lost by at-
|
|
||||||
[]
|
|
||||||
|
|
||||||
|
|
||||||
Overfull \hbox (17.62482pt too wide) in paragraph at lines 179--180
|
|
||||||
[][]
|
|
||||||
[]
|
|
||||||
|
|
||||||
[10] [11] [12]
|
|
||||||
No file casper_basic_structure.bbl.
|
No file casper_basic_structure.bbl.
|
||||||
[13] (./casper_basic_structure.aux) )
|
[8] (./casper_basic_structure.aux) )
|
||||||
Here is how much of TeX's memory you used:
|
Here is how much of TeX's memory you used:
|
||||||
1610 strings out of 494953
|
1610 strings out of 494953
|
||||||
22932 string characters out of 6180977
|
22932 string characters out of 6180977
|
||||||
81571 words of memory out of 5000000
|
80571 words of memory out of 5000000
|
||||||
4895 multiletter control sequences out of 15000+600000
|
4895 multiletter control sequences out of 15000+600000
|
||||||
9456 words of font info for 33 fonts, out of 8000000 for 9000
|
9456 words of font info for 33 fonts, out of 8000000 for 9000
|
||||||
14 hyphenation exceptions out of 8191
|
14 hyphenation exceptions out of 8191
|
||||||
37i,10n,23p,978b,181s stack positions out of 5000i,500n,10000p,200000b,80000s
|
37i,6n,23p,1062b,181s stack positions out of 5000i,500n,10000p,200000b,80000s
|
||||||
</usr/share/texlive/texmf-dist/fonts/type1
|
</usr/share/texlive/texmf-dist/fonts/type1/
|
||||||
/public/amsfonts/cm/cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/publi
|
public/amsfonts/cm/cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public
|
||||||
c/amsfonts/cm/cmbx12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsf
|
/amsfonts/cm/cmbx12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfo
|
||||||
onts/cm/cmex10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/c
|
nts/cm/cmmi12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm
|
||||||
m/cmmi12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi
|
/cmmi8.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.
|
||||||
6.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi8.pfb><
|
pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr12.pfb></u
|
||||||
/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/sh
|
sr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb></usr/shar
|
||||||
are/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr12.pfb></usr/share/tex
|
e/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texliv
|
||||||
live/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb></usr/share/texlive/te
|
e/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texm
|
||||||
xmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texlive/texmf-dist
|
f-dist/fonts/type1/public/amsfonts/cm/cmti12.pfb>
|
||||||
/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-dist/fonts
|
Output written on casper_basic_structure.pdf (8 pages, 144071 bytes).
|
||||||
/type1/public/amsfonts/cm/cmsy8.pfb></usr/share/texlive/texmf-dist/fonts/type1/
|
|
||||||
public/amsfonts/cm/cmti12.pfb>
|
|
||||||
Output written on casper_basic_structure.pdf (13 pages, 185707 bytes).
|
|
||||||
PDF statistics:
|
PDF statistics:
|
||||||
99 PDF objects out of 1000 (max. 8388607)
|
71 PDF objects out of 1000 (max. 8388607)
|
||||||
70 compressed objects within 1 object stream
|
50 compressed objects within 1 object stream
|
||||||
0 named destinations out of 1000 (max. 500000)
|
0 named destinations out of 1000 (max. 500000)
|
||||||
1 words of extra memory for PDF output out of 10000 (max. 10000000)
|
1 words of extra memory for PDF output out of 10000 (max. 10000000)
|
||||||
|
|
||||||
|
|
|
||||||
Binary file not shown.
|
|
@ -16,8 +16,18 @@
|
||||||
We give an introduction to the non-economic details of Casper: the Friendly Finality Gadget, Phase 1.
|
We give an introduction to the non-economic details of Casper: the Friendly Finality Gadget, Phase 1.
|
||||||
\end{abstract}
|
\end{abstract}
|
||||||
|
|
||||||
|
\section{Principles}
|
||||||
|
Casper the Friendly Finality Gadget is designed as an overlay that must be built on top of some kind of ``proposal mechanism'' - a mechanism which ``proposes'' blocks which the Casper mechanism can then set in stone by ``finalizing'' them. The Casper mechanism depends on the proposal mechanism for liveness, but not safety; that is, if the proposal mechanism is entirely corrupted and controlled by adversaries, then the adversaries can prevent Casper from finalizing any blocks, but cannot cause a safety failure in Casper; that is, they cannot force Casper to finalize two conflicting blocks.
|
||||||
|
|
||||||
|
The base mechanism is heavily inspired by partially synchronous systems such as Tendermine [cite] and PBFT [cite], and thus has $\frac{1}{3}$ Byzantine fault tolerance and is safe under asynchrony and dependent on the proposal mechanism for liveness. We later introduce a modification which increases Byzantine fault tolerance to $\frac{1}{2}$, with the proviso that attackers with size $\frac{1}{3} < x < \frac{1}{2}$ can delay new blocks being finalized by some period of time $D$ (think $D \approx$ 3 weeks), at the cost of a ``tradeoff synchrony assumption'' where fault tolerance decreases as network latency goes up, decreasing to zero when network latency reaches $D$.
|
||||||
|
|
||||||
|
In the Casper Phase 1 implementation for Ethereum, the ``proposal mechanism'' is the existing proof of work chain, modified to have a greatly reduced block reward because the chain no longer relies as heavily on proof of work for security, and we describe how the Casper mechanism, and fork choice rule, can be ``overlaid'' onto the proof of work mechanism in order to add Casper's guarantees.
|
||||||
|
|
||||||
\section{Introduction, Protocol I}
|
\section{Introduction, Protocol I}
|
||||||
In the Casper protocol, there is a set of validators, and in each epoch validators have the ability to send two kinds of messages: $$[PREPARE, epoch, hash, epoch_{source}, hash_{source}]$$ and $$[COMMIT, epoch, hash]$$
|
|
||||||
|
In the Casper protocol, there exists a set of validators, and in each \textit{epoch} (see below) validators have the ability to send two kinds of messages: $$[PREPARE, epoch, hash, epoch_{source}, hash_{source}]$$ and $$[COMMIT, epoch, hash]$$
|
||||||
|
|
||||||
|
[diagram]
|
||||||
|
|
||||||
An \textit{epoch} is a period of 100 epochs; epoch $n$ begins at block $n * 100$ and ends at block $n * 100 + 99$. A \textit{checkpoint for epoch $n$} is a block with number $n * 100 - 1$; in a smoothly running blockchain there will usually be one checkpoint per epoch, but due to network latency or deliberate attacks there may be multiple competing checkpoints. The \textit{parent checkpoint} of a checkpoint is the 100th ancestor of the checkpoint block, and an \textit{ancestor checkpoint} of a checkpoint is either the parent checkpoint, or an ancestor checkpoint of the parent checkpoint. We define the \textit{ancestry hash} of a checkpoint as follows:
|
An \textit{epoch} is a period of 100 epochs; epoch $n$ begins at block $n * 100$ and ends at block $n * 100 + 99$. A \textit{checkpoint for epoch $n$} is a block with number $n * 100 - 1$; in a smoothly running blockchain there will usually be one checkpoint per epoch, but due to network latency or deliberate attacks there may be multiple competing checkpoints. The \textit{parent checkpoint} of a checkpoint is the 100th ancestor of the checkpoint block, and an \textit{ancestor checkpoint} of a checkpoint is either the parent checkpoint, or an ancestor checkpoint of the parent checkpoint. We define the \textit{ancestry hash} of a checkpoint as follows:
|
||||||
|
|
||||||
|
|
@ -30,7 +40,7 @@ Ancestry hashes thus form a direct hash chain, and otherwise have a one-to-one c
|
||||||
|
|
||||||
During epoch $n$, validators are expected to send prepare and commit messages specifying epoch $n$, and the ancestry hash of a checkpoint for epoch $n$ (i.e. with block number $n * 100 - 1$). Prepare messages are expected to specify as $hash_{source}$ a checkpoint for any previous epoch which is \textit{justified} (see below), and the $epoch_{source}$ is expected to be the epoch of that checkpoint.
|
During epoch $n$, validators are expected to send prepare and commit messages specifying epoch $n$, and the ancestry hash of a checkpoint for epoch $n$ (i.e. with block number $n * 100 - 1$). Prepare messages are expected to specify as $hash_{source}$ a checkpoint for any previous epoch which is \textit{justified} (see below), and the $epoch_{source}$ is expected to be the epoch of that checkpoint.
|
||||||
|
|
||||||
Each validator has a \textit{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 as the validator receives rewards and penalties. For the rest of this paper, when we say ``$\frac{2}{3}$ of validators", we are referring to a \textit{deposit-weighted} fraction; that is, a set of validators whose combined deposit size equals to at least $\frac{2}{3}$ of the total deposit size of the entire set of validators. We also use ``$\frac{2}{3}$ commits" as shorthand for ``commits from $\frac{2}{3}$ of validators".
|
Each validator has a \textit{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 as the validator receives rewards and penalties. For the rest of this paper, when we say ``$\frac{2}{3}$ of validators", we are referring to a \textit{deposit-weighted} fraction; that is, a set of validators whose combined deposit size equals to at least $\frac{2}{3}$ of the total deposit size of the entire set of validators. We also use ``$\frac{2}{3}$ commits" as shorthand for ``commits from $\frac{2}{3}$ of validators". At first, we will consider the set of validators, and their deposit sizes, static, but in later sections we will introduce the notion of validator set changes.
|
||||||
|
|
||||||
If, during an epoch $e$, for some specific ancestry hash $h$, for any specific ($epoch_{source}, hash_{source}$ pair), there exist $\frac{2}{3}$ prepares of the form $$[PREPARE, e, h, epoch_{source}, hash_{source}]$$, then $h$ is considered \textit{justified}. If $\frac{2}{3}$ commits are sent of the form $$[COMMIT, e, h]$$ then $h$ is considered \textit{finalized}.
|
If, during an epoch $e$, for some specific ancestry hash $h$, for any specific ($epoch_{source}, hash_{source}$ pair), there exist $\frac{2}{3}$ prepares of the form $$[PREPARE, e, h, epoch_{source}, hash_{source}]$$, then $h$ is considered \textit{justified}. If $\frac{2}{3}$ commits are sent of the form $$[COMMIT, e, h]$$ then $h$ is considered \textit{finalized}.
|
||||||
|
|
||||||
|
|
@ -65,165 +75,66 @@ This implies $\frac{2}{3}$ commits and $\frac{2}{3}$ prepares in epochs $e_A$ an
|
||||||
|
|
||||||
Now, we prove liveness. Suppose that all existing validators have sent some sequence of prepare and commit messages. Let $M$ with epoch $e_M$ be the highest-epoch checkpoint that was justified. Honest validators have not committed on any block which is not justified. Hence, neither slashing condition stops them from making prepares on a child of $M$, using $e_M$ as $epoch_{source}$, and then committing this child.
|
Now, we prove liveness. Suppose that all existing validators have sent some sequence of prepare and commit messages. Let $M$ with epoch $e_M$ be the highest-epoch checkpoint that was justified. Honest validators have not committed on any block which is not justified. Hence, neither slashing condition stops them from making prepares on a child of $M$, using $e_M$ as $epoch_{source}$, and then committing this child.
|
||||||
|
|
||||||
\section{Dynamic Validator Sets}
|
\section{Fork Choice Rule}
|
||||||
|
|
||||||
We define the following constants and functions:
|
The mechanism described above ensures \textit{plausible liveness}; however, it by itself does not ensure \textit{actual liveness} - that is, while the mechanism cannot get stuck in the strict sense, it could still enter a scenario where the proposal mechanism (i.e. the proof of work chain) gets into a state where it never ends up creating a checkpoint that could get finalized.
|
||||||
|
|
||||||
\begin{itemize}
|
Here is one possible example:
|
||||||
\item $BIR(D)$: determines the base interest rate paid to each validator, taking as an input the current total quantity of deposited ether.
|
|
||||||
\item $BP(D, e, LFE)$: determines the ``base penalty constant'' - a value expressed as a percentage rate that is used as the ``scaling factor'' for all penalties; for example, if at the current time $BP(...) = 0.001$, then a penalty of size $1.5$ means a validator loses $0.15\%$ of their deposit. Takes as inputs the current total quantity of deposited ether $D$, the current epoch $e$ and the last finalized epoch $LFE$. Note that in a ``perfect'' protocol execution, $e - LFE$ always equals $1$.
|
|
||||||
\item $NCP$ (``non-commit penalty''): the penalty for not committing, if there was a justified hash which the validator \textit{could} have committed
|
|
||||||
\item $NCCP(\alpha)$ (``non-commit collective penalty''): if $\alpha$ of validators are not seen to have committed during an epoch, and that epoch had a justified hash so any validator \textit{could} have committed, then all validators are charged a penalty proportional to $NCCP(\alpha)$. Must be monotonically increasing, and satisfy $NCCP(0) = 0$.
|
|
||||||
\item $NPP$ (``non-prepare penalty''): the penalty for not preparing
|
|
||||||
\item $NPCP(\alpha)$ (``non-prepare collective penalty''): if $\alpha$ of validators are not seen to have prepared during an epoch, then all validators are charged a penalty proportional to $NCCP(\alpha)$. Must be monotonically increasing, and satisfy $NPCP(0) = 0$.
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
Note that preparing and committing does not guarantee that the validator will not incur $NPP$ and $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 know about them. For $NPCP$ and $NCCP$ similarly, the $\alpha$ input is the portion of validators whose prepares and commits are \textit{included}, not the portion of validators who \textit{tried to send} prepares and commits.
|
[https://cdn-images-1.medium.com/max/800/1*IhXmzZG9toAs3oedZX0spg.jpeg]
|
||||||
|
|
||||||
When we talk about preparing and committing the ``correct value", we are referring to the $hash$ and $epoch_{source}$ and $hash_{source}$ recommended by the protocol state, as described above.
|
In this case, $HASH1$ or any descendant thereof cannot be finalized without slashing $\frac{1}{6}$ of validators. However, miners on a proof of work chain would interpret $HASH1$ as the head and start mining descendants of it.
|
||||||
|
|
||||||
We now define the following reward and penalty schedule, which runs every epoch.
|
In fact, when \textit{any} checkpoint gets $k > \frac{1}{3}$ commits, no conflicting checkpoint can get finalized without $k - \frac{1}{3}$ of validators getting slashed. This necessitates modifying the fork choice rule used by participants in the underlying proposal mechanism (as well as users and validators): instead of blindly following a longest-chain rule, there needs to be an overriding rule that (i) finalized checkpoints are favored, and (ii) when there are no further finalized checkpoints, checkpoints with more (justified) commits are favored.
|
||||||
|
|
||||||
\begin{itemize}
|
One complete description of such a rule would be:
|
||||||
\item Let $D$ be the current total quantity of deposited ether, and $e - LFE$ be the number of epochs since the last finalized epoch.
|
|
||||||
\item All validators get a reward of $BIR(D)$ every epoch (eg. if $BIR(D) = 0.0002$ then a validator with $10000$ 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 given epoch, they are penalized $BP(D, e, LFE) * NPP$
|
|
||||||
\item If the protocol saw prepares from portion $p_p$ validators during the given epoch, \textit{every} validator is penalized $BP(D, e, LFE) * NPCP(1 - p_p)$
|
|
||||||
\item If the protocol does not see a commit from a given validator during the given epoch, and a prepare was justified so a commit \textit{could have} been seen, they are penalized $BP(D, E, LFE) * NCP$.
|
|
||||||
\item If the protocol saw commits from portion $p_c$ validators during the given epoch, and a prepare was justified so any validator \textit{could have} committed, then \textit{every} validator is penalized $BP(D, e, LFE) * NCCP(1 - p_p)$
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
This is the entirety of the incentivization structure, though without functions and constants defined; we will define these later, attempting as much as possible to derive the specific values from desired objectives and first principles. For now we will only say that all constants are positive and all functions output non-negative values for any input within their range. Additionally, $NPCP(0) = NCCP(0) = 0$ and $NPCP$ and $NCCP$ must both be nondecreasing.
|
|
||||||
|
|
||||||
\section{Claims}
|
|
||||||
|
|
||||||
We seek to prove the following:
|
|
||||||
|
|
||||||
\begin{itemize}
|
|
||||||
\item If each validator has less than $\frac{1}{3}$ of total deposits, then preparing and committing the value suggested by the proposal mechanism is a Nash equilibrium.
|
|
||||||
\item Even if all validators collude, the ratio between the harm incurred by the protocol and the penalties paid by validators is bounded above by some constant. Note that this requires a measure of ``harm incurred by the protocol"; we will discuss this in more detail later.
|
|
||||||
\item The \textit{griefing factor}, the ratio between penalties incurred by validators who are victims of an attack and penalties incurred by the validators that carried out the attack, can be bounded above by 2, even in the case where the attacker holds a majority of the total deposits.
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
\section{Individual choice analysis}
|
|
||||||
|
|
||||||
The individual choice analysis is simple. Suppose that the proposal mechanism selects a hash $H$ to prepare for epoch $e$, and the Casper incentivization mechanism specifies some $epoch_{source}$ and $hash_{source}$. Because, as per definition of the Nash equilibrium, we are assuming that all validators except for one particular validator that we are analyzing is following the equilibrium strategy, we know that $\ge \frac{2}{3}$ of validators prepared in the last epoch and so $epoch_{source} = e - 1$, and $hash_{source}$ is the direct parent of $H$.
|
|
||||||
|
|
||||||
Hence, the PREPARE\_COMMIT\_CONSISTENCY slashing condition poses no barrier to preparing $(e, H, epoch_{source}, hash_{source})$. Since, in epoch $e$, we are assuming that all other validators \textit{will} prepare these values and then commit $H$, we know $H$ will be the hash in the main chain, and so a validator will pay a penalty proportional to $NPP$ (plus a further penalty from their marginal contribution to the $NPCP$ penalty) if they do not prepare $(e, H, epoch_{source}, hash_{source})$, and they can avoid this penalty if they do prepare these values.
|
|
||||||
|
|
||||||
We are assuming that there are $\frac{2}{3}$ prepares for $(e, H, epoch_{source}, hash_{source})$, and so PREPARE\_REQ poses no barrier to committing $H$. Committing $H$ allows a validator to avoid $NCP$ (as well as their marginal contribution to $NCCP$). Hence, there is an economic incentive to commit $H$. 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.
|
|
||||||
|
|
||||||
\section{Collective choice model}
|
|
||||||
|
|
||||||
To model the protocol in a collective-choice context, we will first define a \textit{protocol utility function}. The protocol utility function defines ``how well the protocol execution is doing". The protocol utility function cannot be derived mathematically; it can only be conceived and justified intuitively.
|
|
||||||
|
|
||||||
Our protocol utility function is:
|
|
||||||
|
|
||||||
$$U = \sum_{e = 0}^{e_c} -log_2(e - LFE(e)) - M * F$$
|
|
||||||
|
|
||||||
Where:
|
|
||||||
|
|
||||||
\begin{itemize}
|
|
||||||
\item $e$ is the current epoch, going from epoch $0$ to $e_c$, the current epoch
|
|
||||||
\item $LFE(e)$ is the last finalized epoch before $e$
|
|
||||||
\item $M$ is a very large constant
|
|
||||||
\item $F$ is 1 if a safety failure has taken place, otherwise 0
|
|
||||||
\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 $e$ 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 * (log_2(N) - \frac{1}{ln(2)})$. 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 \textit{increasing the finality time of a blockchain by a constant factor causes a constant loss of utility}. The utility difference between 1 minute finality and 2 minute finality is the same as the utility difference between 1 hour finality and 2 hour finality.
|
|
||||||
|
|
||||||
This can be justified in two ways. First, one can intuitively argue that a user's psychological estimation of the discomfort of waiting for finality roughly matches this kind of logarithmic utility schedule. At the very least, it should be clear that the difference between 3600 second finality and 3610 second finality feels much more negligible than the difference between 1 second finality and 11 second finality, and so the claim that the difference between 10 second finality and 20 second finality is similar to the difference between 1 hour finality and 2 hour finality should not seem farfetched. Second, 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).
|
|
||||||
|
|
||||||
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) have $\ge \frac{1}{3}$ of validators not prepare or not commit to prevent finality. In the first case, validators lose a large amount of deposits for violating the slashing conditions. In the second case, in a chain that has not been finalized for $e - LFE$ epochs, the penalty to attackers is $$min(NPP * \frac{1}{3} + NPCP(\frac{1}{3}), NCP * \frac{1}{3} + NCCP(\frac{1}{3})) * BP(D, e, LFE)$$
|
|
||||||
|
|
||||||
To enforce a ratio between validator losses and loss to protocol utility, we set:
|
|
||||||
|
|
||||||
$$BP(D, e, LFE) = \frac{k}{D^p} + k_2 * floor(log_2(e - LFE))$$
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
\section{Griefing factor analysis}
|
|
||||||
|
|
||||||
Griefing factor analysis is important because it provides one way to quanitfy the risk to honest validators. In general, if all validators are honest, and if network latency stays below the length of an epoch, then validators face zero risk beyond the usual risks of losing or accidentally divulging access to their private keys. In the case where malicious validators exist, however, they can interfere in the protocol in ways that cause harm to both themselves and honest validators.
|
|
||||||
|
|
||||||
We can approximately define the "griefing factor" as follows:
|
|
||||||
|
|
||||||
\begin{definition}
|
|
||||||
A strategy used by a coalition in a given mechanism exhibits a \textit{griefing factor} $B$ if it can be shown that this strategy imposes a loss of $B * x$ to those outside the coalition at the cost of a loss of $x$ to those inside the coalition. If all strategies that cause deviations from some given baseline state exhibit griefing factors less than or equal to some bound B, then we call B a \textit{griefing factor bound}.
|
|
||||||
\end{definition}
|
|
||||||
|
|
||||||
A strategy that imposes a loss to outsiders either at no cost to a coalition, or to the benefit of a coalition, is said to have a griefing factor of infinity. Proof of work blockchains have a griefing factor bound of infinity because a 51\% coalition can double its revenue by refusing to include blocks from other participants and waiting for difficulty adjustment to reduce the difficulty. With selfish mining, the griefing factor may be infinity for coalitions of size as low as 23.21\%.
|
|
||||||
|
|
||||||
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}
|
\begin{enumerate}
|
||||||
\item A minority of validators do not prepare, or prepare incorrect values.
|
\item Start with HEAD equal to the genesis of the chain.
|
||||||
\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 $H1$ and then preparing $H2$, making $H2$ the dominant chain and denying the victims their rewards)
|
\item Select the descendant checkpoint of HEAD with the most commits (only justified checkpoints are admissible)
|
||||||
\item A minority of validators do not commit.
|
\item Repeat (2) until no descendant with commits exists.
|
||||||
\item (Mirror image of 3) A censorship attack where a majority of validators does not accept commits from a minority of validators
|
\item Choose the longest proof of work chain from there.
|
||||||
\end{enumerate}
|
\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 $DF(D, e, LFE)$, the penalty scaling factor. This value scales penalties evenly for all participants, so it does not affect griefing factors.
|
The commit-following part of this rule can be viewed in some ways as mirroring the "greegy heaviest observed subtree" (GHOST) rule that has been proposed for proof of work chains [cite]. The symmetry is this: in GHOST, a node starts with the head at the genesis, then begins to move forward down the chain, and if it encounters a block with multiple children then it chooses the child that has the larger quantity of work built on top of it (including the child block itself and its descendants).
|
||||||
|
|
||||||
Let us now analyze the attack types:
|
Here, we follow a similar approach, except we repeatedly seek the child that comes the closest to achieving finality. Commits on a descendant are implicitly commits on all of its ancestors, and so if a given descendant of a given block has more commits than any other descendant, then we know that all children along the chain from the head to this descendant are closer to finality than any of their siblings; hence, looking for the \textit{descendant} with the most commits and not just the \textit{child} replicates the GHOST principle most faithfully. Finalizing a checkpoint requires 2/3 commits within a single epoch, and so we do not try to sum up commits across epochs and instead simply take the maximum.
|
||||||
|
|
||||||
\begin{tabularx}{\textwidth}{|X|X|X|}
|
This rule ensures that if there is a checkpoint such that no conflicting checkpoint can be finalized without at least some validators violating slashing conditions, then this is the checkpoint that will be viewed as the ``head'' and thus that validators will try to commit on.
|
||||||
\hline
|
|
||||||
Attack & Amount lost by attacker & Amount lost by victims \\
|
|
||||||
\hline
|
|
||||||
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$ \\
|
|
||||||
\hline
|
|
||||||
\end{tabularx}
|
|
||||||
|
|
||||||
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 < \frac{2}{3}$ commits is better than seeing fewer commits, as it gives at least some economic security against finality reversions, so we do want to reward this scenario more than the scenario where we get $\frac{1}{3} \le p_c < \frac{2}{3}$ prepares. Another way to view the situation is to observe that $\frac{1}{3}$ non-prepares causes \textit{everyone} to non-commit, so it should be treated with equal severity.
|
\section{Dynamic Validator Sets}
|
||||||
|
|
||||||
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$.
|
In an open protocol, the validator set needs to be able to change; old validators need to be able to withdraw, and new validators need to be able to enter. To accomplish this end, we define a variable kept track of in the state called the \textit{dynasty} counter. When a user sends a ``deposit'' transaction to become a validator, if this transaction is included in dynasty $n$, then the validator will be \textit{inducted} in dynasty $n+2$. The dynasty counter is incremented when the chain detects that the checkpoint of the current epoch that is part of its own history has been finalized (that is, the checkpoint of epoch $e$ must be finalized during epoch $e$, and the chain must learn about this before epoch $e$ ends). In simpler terms, when a user sends a ``deposit'' transaction, they need to wait for the transaction to be finalized, and then they need to wait again for that epoch to be finalized; after this, they become part of the validator set. We call such a validator's \textit{start dynasty} $n+2$.
|
||||||
|
|
||||||
Now, let us analyze the griefing factors, to try to determine an optimal shape for $NCCP$. The griefing factor for non-committing is:
|
For a validator to leave, they must send a ``withdraw'' message. If their withdraw message gets included during dynasty $n$, the validator similarly leaves the validator set during dynasty $n+2$; we call $n+2$ their \textit{end dynasty}. When a validator withdraws, their deposit is locked for four months before they can take their money out; if they are caught violating a slashing condition within that time then their deposit is forfeited.
|
||||||
|
|
||||||
$$\frac{(1-\alpha) * NCCP(\alpha)}{\alpha * (1 + NCCP(\alpha))}$$
|
For a checkpoint to be justified, it must be prepared by a set of validators which contains (i) at least $\frac{2}{3}$ of the current dynasty (that is, validators with $startDynasty \le curDynasty < endDynasty$), and (ii) at least $\frac{2}{3}$ of the previous dyansty (that is, validators with $startDynasty \le curDynasty - 1 < endDynasty$. Finalization with commits works similarly. The current and previous dynasties will usually mostly overlap; but in cases where they substantially diverge this ``stitching'' mechanism ensures that dynasty divergences do not lead to situations where a finality reversion or other failure can happen because different messages are signed by different validator sets and so equivocation is avoided.
|
||||||
|
|
||||||
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:
|
[diagram]
|
||||||
|
|
||||||
$$\alpha * (1 + NCCP(\alpha)) = (1-\alpha) * NCCP(\alpha)$$
|
\section{Mass Crash Failure Recovery}
|
||||||
|
|
||||||
$$\frac{1 + NCCP(\alpha)}{NCCP(\alpha)} = \frac{1-\alpha}{\alpha}$$
|
Suppose that more than one third of validators crash-fail at the same time; that is, they either are no longer connected to the network due to a network partition, or their computers fail, or they do this as a malicious attack. Then, no checkpoint will be able to get finalized.
|
||||||
|
|
||||||
$$\frac{1}{NCCP(\alpha)} = \frac{1-\alpha}{\alpha} - 1$$
|
We can recover from this by instituting a rule that validators who do not prepare or commit for a long time start to see their deposit sizes decrease (depending on the desired economic incentives this can be either a compulsory partial withdrawal or an outright confiscation), until eventually their deposit sizes decrease low enough that the validators that \textit{are} preparing and committing are once again a $\frac{2}{3}$ supermajority.
|
||||||
|
|
||||||
$$NCCP(\alpha) = \frac{\alpha}{1-2\alpha}$$
|
Note that this does introduce the possibility of two conflicting checkpoints being finalized, with validators only losing money on one of the two checkpoints:
|
||||||
|
|
||||||
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 \textit{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$.
|
[diagram http://vitalik.ca/files/CommitsSync.png]
|
||||||
|
|
||||||
\section{Pools}
|
If the goal is simply to achieve maximally close to 50\% fault tolerance, then clients should simply favor the finalized checkpoint that they received earlier. However, if clients are also interested in defeating 51\% censorship attacks, then they may want to at least sometimes choose the minority chain. All forms of ``51\% attacks'' can thus be resolved fairly cleanly via ``user-activated soft forks'' that reject what would normally be the dominant chain. Particularly, note that finalizing even one block on the dominant chain precludes the attacking validators from preparing on the minority chain because of \textbf{PREPARE\_COMMIT\_CONSISTENCY}, at least until their balances decrease to the point where the minority can commit, so such a fork would also serve the function of costing the majority attacker a very large portion of their deposits.
|
||||||
|
|
||||||
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''.
|
|
||||||
|
|
||||||
Two other reasons to participate in stake pools are (i) to mitigate \textit{key theft risk} (i.e. an attacker hacking into their online machine and stealing the key), and (ii) to mitigate \textit{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.
|
|
||||||
|
|
||||||
There are several possible kinds of stake pools:
|
|
||||||
|
|
||||||
\begin{itemize}
|
|
||||||
\item \textbf{Fully centrally managed}: users $B_1 ... B_n$ send coins to pool operator $A$. $A$ makes a few deposit transactions containing their combined balances, fully controls the prepare and commit process, and occasionally withdraws one of their deposits to accommodate users wishing to withdraw their balances. Requires complete trust.
|
|
||||||
\item \textbf{Centrally managed but trust-reduced}: users $B_1 ... B_n$ send coins to a pool contract. The contract sends a few deposit transactions containing their combined balances, assigning pool operator $A$ control over the prepare and commit process, and the task of keeping track of withdrawal requests. $A$ occasionally withdraws one of their deposits to accommodate users wishing to withdraw their balances; the withdrawals go directly into the contract, which ensures each user's right to withdraw a proportional share. Users need to trust the operator not to get their coins lose, but the operator cannot steal the coins. The trust requirement can be reduced further if the pool operator themselves contributes a large portion of the coins, as this will disincentivize them from staking maliciously.
|
|
||||||
\item \textbf{2-of-3}: a user makes a deposit transaction and specifies as validation code a 2-of-3 multisig, consisting of (i) the user's online key, (ii) the pool operator's online key, and (iii) the user's offline backup key. The need for two keys to sign off on a prepare, commit or withdraw minimizes key theft risk, and a liveness failure on the pool side can be handled by the user sending their backup key to another pool.
|
|
||||||
\item \textbf{Multisig managed}: users $B_1 ... B_n$ send coins to a pool contract that works in the exact same way as a centrally managed pool, except that a multisig of several semi-trusted parties needs to approve each prepare and commit message.
|
|
||||||
\item \textbf{Collective}: users $B_1 ... B_n$ send coins to a pool contract that that works in the exact same way as a centrally managed poolg
|
|
||||||
, except that a threshold signature of at least portion $p$ of the users themselves (say, $p = 0.6$) needs to approve each prepare and commit messagge.
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
We expect pools of different types to emerge to accomodate smaller users. In the long term, techniques such as blockchain sharding will make it possible to increase the number of users that can participate as validators directly, and techniques that allow validators to temporarily ``log out'' of the validator set when they are offline can mitigate liveness risk.
|
|
||||||
|
|
||||||
\section{Conclusions}
|
\section{Conclusions}
|
||||||
|
|
||||||
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.
|
This introduces the basic workings of Casper the Friendly Finality Gadget's prepare and commit mechanism and fork choice rule, in the context of Byzantine fault tolerance analysis. Separate papers will serve the role of explaining and analyzing incentives inside of Casper, and the different ways that they can be parametrized and the consequences of these paramtrizations.
|
||||||
|
|
||||||
\section{References}
|
\section{References}
|
||||||
\bibliographystyle{abbrv}
|
\bibliographystyle{abbrv}
|
||||||
\bibliography{main}
|
\bibliography{main}
|
||||||
Optimal selfish mining strategies in Bitcoin; Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar: https://arxiv.org/pdf/1507.06183.pdf
|
\begin{itemize}
|
||||||
|
\item Aviv Zohar and Yonatan Sompolinsky, ``Fast Money Grows on Trees, not Chains'': https://eprint.iacr.org/2013/881.pdf
|
||||||
|
\item Jae Kwon, ``Tendermint'': http://tendermint.org/tendermint.pdf
|
||||||
|
\item ...., ``Practical Byzantine Fault Tolerance'': ...
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
\end{document}
|
\end{document}
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue