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

Changes to basic structure paper

This commit is contained in:
Vitalik Buterin 2017-08-15 04:11:54 -04:00
parent 13f0326e5e
commit 28b6d42fae
4 changed files with 81 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
papers/casper/casper_basic_structure.aux
View File

@ -1,12 +1,13 @@
\relax
\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}}
\@writefile{toc}{\contentsline {section}{\numberline {2}Rewards and Penalties}{2}}
\@writefile{toc}{\contentsline {section}{\numberline {3}Claims}{4}}
\@writefile{toc}{\contentsline {section}{\numberline {4}Individual choice analysis}{5}}
\@writefile{toc}{\contentsline {section}{\numberline {5}Collective choice model}{5}}
\@writefile{toc}{\contentsline {section}{\numberline {6}Griefing factor analysis}{7}}
\@writefile{toc}{\contentsline {section}{\numberline {7}Pools}{9}}
\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction, Protocol I}{1}}
\@writefile{toc}{\contentsline {section}{\numberline {2}Proof Sketch of Safety and Plausible Liveness}{3}}
\@writefile{toc}{\contentsline {section}{\numberline {3}Dynamic Validator Sets}{4}}
\@writefile{toc}{\contentsline {section}{\numberline {4}Claims}{6}}
\@writefile{toc}{\contentsline {section}{\numberline {5}Individual choice analysis}{6}}
\@writefile{toc}{\contentsline {section}{\numberline {6}Collective choice model}{7}}
\@writefile{toc}{\contentsline {section}{\numberline {7}Griefing factor analysis}{9}}
\@writefile{toc}{\contentsline {section}{\numberline {8}Pools}{11}}
\bibstyle{abbrv}
\bibdata{main}
\@writefile{toc}{\contentsline {section}{\numberline {8}Conclusions}{11}}
\@writefile{toc}{\contentsline {section}{\numberline {9}References}{11}}
\@writefile{toc}{\contentsline {section}{\numberline {9}Conclusions}{13}}
\@writefile{toc}{\contentsline {section}{\numberline {10}References}{13}}

57
papers/casper/casper_basic_structure.log
View File

@ -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) 7 AUG 2017 03:41
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
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
@ -76,7 +76,7 @@ Package: array 2014/10/28 v2.4c Tabular extension package (FMi)
)
\c@definition=\count89
No file casper_basic_structure.aux.
(./casper_basic_structure.aux)
\openout1 = `casper_basic_structure.aux'.
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 13.
@ -91,6 +91,7 @@ LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 13.
LaTeX Font Info: ... okay on input line 13.
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 13.
LaTeX Font Info: ... okay on input line 13.
(/usr/share/texlive/texmf-dist/tex/context/base/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
\scratchcounter=\count90
@ -162,56 +163,60 @@ LaTeX Font Info: External font `cmex10' loaded for size
(Font) <8> on input line 20.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <6> on input line 20.
[1
{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}]
LaTeX Font Info: Try loading font information for OMS+cmr on input line 29.
LaTeX Font Info: Try loading font information for OMS+cmr on input line 25.
(/usr/share/texlive/texmf-dist/tex/latex/base/omscmr.fd
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
(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 29.
[2] [3] [4]
Overfull \hbox (10.7546pt too wide) in paragraph at lines 80--81
(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 25.
[1
{/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-
pare two dif-fer-ent check-
[]
[3] [4] [5]
Overfull \hbox (10.7546pt too wide) in paragraph at lines 112--113
[]\OT1/cmr/m/n/12 Hence, the PRE-PARE[]COMMIT[]CONSISTENCY slash-ing con-di-tio
n poses
[]
Overfull \hbox (5.39354pt too wide) in paragraph at lines 82--83
[6]
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 )$,
[]
[5]
Overfull \hbox (15.85455pt too wide) in paragraph at lines 105--105
[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
, $[]$
[]
[6] [7]
Underfull \hbox (badness 3291) in paragraph at lines 147--147
[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 147--148
Overfull \hbox (17.62482pt too wide) in paragraph at lines 179--180
[][]
[]
[8] [9] [10]
[10] [11] [12]
No file casper_basic_structure.bbl.
[11] (./casper_basic_structure.aux) )
[13] (./casper_basic_structure.aux) )
Here is how much of TeX's memory you used:
1608 strings out of 494953
22878 string characters out of 6180977
83571 words of memory out of 5000000
1610 strings out of 494953
22932 string characters out of 6180977
81571 words of memory out of 5000000
4895 multiletter control sequences out of 15000+600000
9456 words of font info for 33 fonts, out of 8000000 for 9000
14 hyphenation exceptions out of 8191
37i,10n,23p,898b,181s stack positions out of 5000i,500n,10000p,200000b,80000s
37i,10n,23p,978b,181s stack positions out of 5000i,500n,10000p,200000b,80000s
</usr/share/texlive/texmf-dist/fonts/type1
/public/amsfonts/cm/cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/publi
c/amsfonts/cm/cmbx12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsf
@ -225,10 +230,10 @@ xmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texlive/texmf-dist
/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-dist/fonts
/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 (11 pages, 178027 bytes).
Output written on casper_basic_structure.pdf (13 pages, 185707 bytes).
PDF statistics:
92 PDF objects out of 1000 (max. 8388607)
65 compressed objects within 1 object stream
99 PDF objects out of 1000 (max. 8388607)
70 compressed objects within 1 object stream
0 named destinations out of 1000 (max. 500000)
1 words of extra memory for PDF output out of 10000 (max. 10000000)

BIN
papers/casper/casper_basic_structure.pdf
View File

Binary file not shown.

48
papers/casper/casper_basic_structure.tex
View File

@ -16,24 +16,56 @@
We give an introduction to the non-economic details of Casper: the Friendly Finality Gadget, Phase 1.
\end{abstract}
\section{Introduction}
\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]$$
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:
\begin{itemize}
\item The ancestry hash of the implied ``genesis checkpoint'' before epoch 0 is zero.
\item The ancestry hash of any other checkpoint is the keccsk256 hash of the ancestry hash of its parent concatenated with the hash of the checkpoint.
\end{itemize}
Ancestry hashes thus form a direct hash chain, and otherwise have a one-to-one correspondence with checkpoint hashes.
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".
If, during an epoch $e$, for some specific checkpoint hash $h$, $\frac{2}{3}$ prepares are sent of the form $$[PREPARE, e, h, epoch_{source}, hash_{source}]$$ with some specific $epoch_{source}$ and some specific $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}. The $hash$ is the block hash of the block at the start of the epoch, so a $hash$ being finalized means that that block, and all of its ancestors, are also finalized. An ``ideal execution'' of the protocol is one where, during every epoch, every validator prepares and commits some block hash at the start of that epoch, specifying the same $epoch_{source}$ and $hash_{source}$. We want to try to create incentives to encourage this ideal execution.
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}.
Possible deviations from this ideal execution that we want to minimize or avoid include:
We add the following modifications:
\begin{itemize}
\item Any of the four slashing conditions get violated.
\item During some epoch, we do not get $\frac{2}{3}$ commits for the $hash$ that received $\frac{2}{3}$ prepares.
\item During some epoch, we do not get $\frac{2}{3}$ prepares for the same \\ $(h, hash_{source}, epoch_{source})$ combination.
\item For a checkpoint to be finalized, it must be justified.
\item For a checkpoint to be justified, the $hash_{source}$ used to justify it must itself be justified.
\item Prepare and commit messages are only accepted as part of blocks; that is, for a client to see $\frac{2}{3}$ commits of some hash, they must receive a block such that in the chain terminating at that block $\frac{2}{3}$ commits for that hash have been processed.
\end{itemize}
From within the view of the blockchain, we only see the blockchain's own history, including messages that were passed in. In a history that contains some blockhash $H$, our strategy will be to reward validators who prepared and committed $H$, and not reward prepares or commits for any hash $H\prime \ne H$. The blockchain state will also keep track of the most recent hash in its own history that received $\frac{2}{3}$ prepares, and only reward prepares whose $epoch_{source}$ and $hash_{source}$ point to this hash. These two techniques will help to ``coordinate'' validators toward preparing and committing a single hash with a single source, as required by the protocol.
This gives substantial gains in implementation simplicity, because this means that we can now have a fork choice rule where the ``score'' of a block only depends on the block and its children, putting it into a similar category as more traditional PoW-based fork choice rules such as the longest chain rule and GHOST. However, this fork choice rule is also \textit{finality-bearing}: it is impossible for two incompatible checkpoints to be finalized unless at least $\frac{1}{3}$ of the validators violated a \textit{slashing condition} (see below).
\section{Rewards and Penalties}
There are two slashing conditions:
\begin{enumerate}
\item \textbf{NO\_DBL\_PREPARE}: a validator cannot prepare two different checkpoints for the same epoch.
\item \textbf{PREPARE\_COMMIT\_CONSISTENCY}: if a validator has made a commit with epoch $n$, they cannot make a prepare with $epoch > n$ and $epoch_{source} < n$.
\end{enumerate}
Earlier versions of Casper had four slashing conditions, but we can reduce to two because of the three modifications above; they ensure that blocks will not register commits or prepares that violate the other two conditions.
\section{Proof Sketch of Safety and Plausible Liveness}
We give a proof sketch of two properties of this scheme: \textit{safety} and \textit{plausible liveness}. Safety means that two incompatible checkpoints cannot be finalized unless at least $\frac{1}{3}$ of validators violate a slashing condition. Plausible liveness means that it is always possible for $\frac{2}{3}$ of honest validators to finalize a new checkpoint, regardless of what previous events took place.
Suppose that two incompatible checkpoints $A$ (epoch $e_A$) and $B$ (epoch $e_B$) are finalized:
[diagram]
This implies $\frac{2}{3}$ commits and $\frac{2}{3}$ prepares in epochs $e_A$ and $e_B$. In the trivial case where $e_A = e_B$, this implies that some intersection of $\frac{1}{3}$ of validators must have violated \textbf{NO\_DBL\_PREPARE}. In other cases, there must exist two chains $e_A > e_A^1 > e_A^2 > ... > G$ and $e_B > e_B^1 > e_B^2 > ... > G$ of justified checkpoints, both terminating at the genesis. Suppose without loss of generality that $e_A > e_B$. Then, there must be some $e_A^i$ that either $e_A^i = e_B$ or $e_A^i > e_B > e_A^{i+1}$. In the first case, since $A^i$ and $B$ both have $\frac{2}{3}$ prepares, at least $\frac{1}{3}$ of validators violated \textbf{NO\_DBL\_PREPARE}. Otherwise, $B$ has $\frac{2}{3}$ commits and there exist $\frac{2}{3}$ prepares with $epoch > B$ and $epoch_{source} < B$, so at least $\frac{1}{3}$ of validators violated \textbf{PREPARE\_COMMIT\_CONSISTENCY}. This proves safety.
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}
We define the following constants and functions: