Added diagrams

This commit is contained in:
Vitalik Buterin 2017-08-16 03:56:06 -04:00
parent 0d71921ef8
commit 9092ee182e
9 changed files with 75 additions and 38 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

View File

@ -3,9 +3,9 @@
\@writefile{toc}{\contentsline {section}{\numberline {2}Introduction, Protocol I}{2}}
\@writefile{toc}{\contentsline {section}{\numberline {3}Proof Sketch of Safety and Plausible Liveness}{4}}
\@writefile{toc}{\contentsline {section}{\numberline {4}Fork Choice Rule}{5}}
\@writefile{toc}{\contentsline {section}{\numberline {5}Dynamic Validator Sets}{6}}
\@writefile{toc}{\contentsline {section}{\numberline {6}Mass Crash Failure Recovery}{7}}
\@writefile{toc}{\contentsline {section}{\numberline {5}Dynamic Validator Sets}{7}}
\@writefile{toc}{\contentsline {section}{\numberline {6}Mass Crash Failure Recovery}{8}}
\bibstyle{abbrv}
\bibdata{main}
\@writefile{toc}{\contentsline {section}{\numberline {7}Conclusions}{8}}
\@writefile{toc}{\contentsline {section}{\numberline {8}References}{8}}
\@writefile{toc}{\contentsline {section}{\numberline {7}Conclusions}{10}}
\@writefile{toc}{\contentsline {section}{\numberline {8}References}{10}}

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) 15 AUG 2017 23:33
This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) (preloaded format=pdflatex 2017.6.27) 16 AUG 2017 03:55
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
@ -167,50 +167,87 @@ LaTeX Font Info: External font `cmex10' loaded for size
[1
{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}]
LaTeX Font Info: Try loading font information for OMS+cmr on input line 35.
<prepares_commits.png, id=14, 1201.288pt x 346.896pt>
File: prepares_commits.png Graphic file (type png)
<use prepares_commits.png>
Package pdftex.def Info: prepares_commits.png used on input line 30.
(pdftex.def) Requested size: 401.50146pt x 115.93695pt.
Overfull \hbox (29.12628pt too wide) in paragraph at lines 30--31
[][]
[]
LaTeX Font Info: Try loading font information for OMS+cmr on input line 35.
(/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 35.
[2]
[2 <./prepares_commits.png>] [3]
Overfull \hbox (1.48117pt too wide) in paragraph at lines 60--61
[]\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]
Overfull \hbox (48.00797pt too wide) in paragraph at lines 84--85
[]\OT1/cmr/m/n/12 [https://cdn-images-1.medium.com/max/800/1*IhXmzZG9toAs3oedZX
0spg.jpeg]
<conflicting_checkpoints.png, id=25, 634.37pt x 403.5075pt>
File: conflicting_checkpoints.png Graphic file (type png)
<use conflicting_checkpoints.png>
Package pdftex.def Info: conflicting_checkpoints.png used on input line 72.
(pdftex.def) Requested size: 301.1261pt x 191.5449pt.
[4] [5 <./conflicting_checkpoints.png>]
<fork_choice_rule.jpeg, id=33, 707.64375pt x 442.65375pt>
File: fork_choice_rule.jpeg Graphic file (type jpg)
<use fork_choice_rule.jpeg>
Package pdftex.def Info: fork_choice_rule.jpeg used on input line 84.
(pdftex.def) Requested size: 401.50146pt x 251.1535pt.
Overfull \hbox (29.12628pt too wide) in paragraph at lines 84--85
[][]
[]
[5] [6] [7]
[6 <./fork_choice_rule.jpeg>] [7]
<validator_set_misalignment.png, id=41, 422.57875pt x 283.0575pt>
File: validator_set_misalignment.png Graphic file (type png)
<use validator_set_misalignment.png>
Package pdftex.def Info: validator_set_misalignment.png used on input line 113.
(pdftex.def) Requested size: 250.93842pt x 168.09088pt.
[8 <./validator_set_misalignment.png (PNG copy)>] <CommitsSync.png, id=45, 422
.57875pt x 373.395pt>
File: CommitsSync.png Graphic file (type png)
<use CommitsSync.png>
Package pdftex.def Info: CommitsSync.png used on input line 123.
(pdftex.def) Requested size: 301.1261pt x 266.08658pt.
[9 <./CommitsSync.png>]
No file casper_basic_structure.bbl.
[8] (./casper_basic_structure.aux) )
[10] (./casper_basic_structure.aux) )
Here is how much of TeX's memory you used:
1610 strings out of 494953
22932 string characters out of 6180977
80571 words of memory out of 5000000
4895 multiletter control sequences out of 15000+600000
1637 strings out of 494953
23600 string characters out of 6180977
79571 words of memory out of 5000000
4915 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,6n,23p,1062b,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/public
/amsfonts/cm/cmbx12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfo
nts/cm/cmmi12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm
/cmmi8.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.
pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr12.pfb></u
sr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb></usr/shar
e/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texliv
e/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texm
f-dist/fonts/type1/public/amsfonts/cm/cmti12.pfb>
Output written on casper_basic_structure.pdf (8 pages, 144071 bytes).
</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
onts/cm/cmmi12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/c
m/cmmi8.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10
.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr12.pfb></
usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb></usr/sha
re/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texli
ve/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/tex
mf-dist/fonts/type1/public/amsfonts/cm/cmti12.pfb>
Output written on casper_basic_structure.pdf (10 pages, 350226 bytes).
PDF statistics:
71 PDF objects out of 1000 (max. 8388607)
50 compressed objects within 1 object stream
86 PDF objects out of 1000 (max. 8388607)
55 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)
26 words of extra memory for PDF output out of 10000 (max. 10000000)

View File

@ -27,7 +27,7 @@ In the Casper Phase 1 implementation for Ethereum, the ``proposal mechanism'' is
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]
\includegraphics[width=400px]{prepares_commits.png}
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:
@ -67,9 +67,9 @@ Earlier versions of Casper had four slashing conditions, but we can reduce to tw
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:
Suppose that two conflicting checkpoints $A$ (epoch $e_A$) and $B$ (epoch $e_B$) are finalized.
[diagram]
\includegraphics[width=300px]{conflicting_checkpoints.png}
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.
@ -81,7 +81,7 @@ The mechanism described above ensures \textit{plausible liveness}; however, it b
Here is one possible example:
[https://cdn-images-1.medium.com/max/800/1*IhXmzZG9toAs3oedZX0spg.jpeg]
\includegraphics[width=400px]{fork_choice_rule.jpeg}
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.
@ -110,7 +110,7 @@ For a validator to leave, they must send a ``withdraw'' message. If their withdr
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.
[diagram]
\includegraphics[width=250px]{validator_set_misalignment.png}
\section{Mass Crash Failure Recovery}
@ -120,7 +120,7 @@ We can recover from this by instituting a rule that validators who do not prepar
Note that this does introduce the possibility of two conflicting checkpoints being finalized, with validators only losing money on one of the two checkpoints:
[diagram http://vitalik.ca/files/CommitsSync.png]
\includegraphics[width=300px]{CommitsSync.png}
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.
@ -134,7 +134,7 @@ This introduces the basic workings of Casper the Friendly Finality Gadget's prep
\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'': ...
\item Miguel Castro and Barbara Liskov, ``Practical Byzantine Fault Tolerance'': http://pmg.csail.mit.edu/papers/osdi99.pdf
\end{itemize}
\end{document}

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 133 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 29 KiB