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

Some modifications to censorship rejection paper

This commit is contained in:
Vitalik Buterin 2017-08-15 00:27:30 -04:00
parent ee9a621f03
commit 13f0326e5e
4 changed files with 39 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
papers/censorship_rejection/censorship_rejection.aux
View File

@ -2,10 +2,10 @@
\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{2}}
\@writefile{toc}{\contentsline {section}{\numberline {2}Forgiving Rejection}{3}}
\@writefile{toc}{\contentsline {section}{\numberline {3}Unforgiving Rejection}{7}}
\@writefile{toc}{\contentsline {section}{\numberline {4}Incentives in the Uncoordinated Majority Model}{9}}
\@writefile{toc}{\contentsline {section}{\numberline {4}Incentives in the Uncoordinated Majority Model}{8}}
\@writefile{toc}{\contentsline {section}{\numberline {5}Incentives in the Majority Attacker Model}{10}}
\@writefile{toc}{\contentsline {section}{\numberline {6}Timelock Timers}{13}}
\@writefile{toc}{\contentsline {section}{\numberline {7}Proof of Work Timers}{14}}
\@writefile{toc}{\contentsline {section}{\numberline {8}Censorship and Transaction Fees}{16}}
\@writefile{toc}{\contentsline {section}{\numberline {6}Timelock Timers}{12}}
\@writefile{toc}{\contentsline {section}{\numberline {7}Proof of Work Timers}{13}}
\@writefile{toc}{\contentsline {section}{\numberline {8}Censorship and Transaction Fees}{15}}
\bibstyle{abbrv}
\bibdata{main}

61
papers/censorship_rejection/censorship_rejection.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) 13 AUG 2017 04:22
This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) (preloaded format=pdflatex 2017.6.27) 15 AUG 2017 00:27
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
@ -155,41 +155,40 @@ Overfull \hbox (29.12628pt too wide) in paragraph at lines 27--28
[][]
[]
Overfull \hbox (20.55408pt too wide) in paragraph at lines 33--34
[2 <./Censorship1.png>]
Overfull \hbox (20.55408pt too wide) in paragraph at lines 35--36
\OT1/cmr/m/n/12 For sim-plic-ity, let us as-sume that there ex-ists a sim-ple N
akamoto-style blockchain,
[]
<Censorship2.png, id=13, 368.37625pt x 156.585pt> [2 <./Censorship1.png>]
<Censorship2.png, id=19, 368.37625pt x 156.585pt>
File: Censorship2.png Graphic file (type png)
<use Censorship2.png>
Package pdftex.def Info: Censorship2.png used on input line 35.
<use Censorship2.png>
Package pdftex.def Info: Censorship2.png used on input line 37.
(pdftex.def) Requested size: 401.50146pt x 170.6647pt.
Overfull \hbox (29.12628pt too wide) in paragraph at lines 35--36
Overfull \hbox (29.12628pt too wide) in paragraph at lines 37--38
[][]
[]
<Censorship3.png, id=20, 372.39125pt x 261.97874pt>
File: Censorship3.png Graphic file (type png)
<use Censorship3.png>
Package pdftex.def Info: Censorship3.png used on input line 41.
Package pdftex.def Info: Censorship3.png used on input line 43.
(pdftex.def) Requested size: 401.50146pt x 282.46912pt.
<Censorship3p5.png, id=21, 457.71pt x 261.97874pt>
File: Censorship3p5.png Graphic file (type png)
<use Censorship3p5.png>
Package pdftex.def Info: Censorship3p5.png used on input line 42.
Package pdftex.def Info: Censorship3p5.png used on input line 44.
(pdftex.def) Requested size: 401.50146pt x 229.81447pt.
Overfull \hbox (29.12628pt too wide) in paragraph at lines 41--43
Overfull \hbox (29.12628pt too wide) in paragraph at lines 43--45
[][]
[]
Overfull \hbox (11.50146pt too wide) in paragraph at lines 41--43
Overfull \hbox (11.50146pt too wide) in paragraph at lines 43--45
[]
[]
@ -197,28 +196,28 @@ Overfull \hbox (11.50146pt too wide) in paragraph at lines 41--43
<Censorship4.png, id=31, 502.87875pt x 237.88875pt>
File: Censorship4.png Graphic file (type png)
<use Censorship4.png>
Package pdftex.def Info: Censorship4.png used on input line 50.
Package pdftex.def Info: Censorship4.png used on input line 52.
(pdftex.def) Requested size: 401.50146pt x 189.9301pt.
Overfull \hbox (29.12628pt too wide) in paragraph at lines 50--51
Overfull \hbox (29.12628pt too wide) in paragraph at lines 52--53
[][]
[]
[5 <./Censorship4.png>] [6]
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <12> on input line 66.
(Font) <12> on input line 68.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <8> on input line 66.
(Font) <8> on input line 68.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <6> on input line 66.
(Font) <6> on input line 68.
<Censorship5.png, id=39, 565.11125pt x 346.29375pt>
File: Censorship5.png Graphic file (type png)
<use Censorship5.png>
Package pdftex.def Info: Censorship5.png used on input line 70.
Package pdftex.def Info: Censorship5.png used on input line 72.
(pdftex.def) Requested size: 401.50146pt x 246.03935pt.
Overfull \hbox (29.12628pt too wide) in paragraph at lines 70--71
Overfull \hbox (29.12628pt too wide) in paragraph at lines 72--73
[][]
[]
@ -232,19 +231,19 @@ Overfull \hbox (29.12628pt too wide) in paragraph at lines 84--85
[][]
[]
[9] [10] <Censorship6b.png, id=56, 693.59125pt x 206.7725pt>
[9] [10] <Censorship6b.png, id=58, 693.59125pt x 206.7725pt>
File: Censorship6b.png Graphic file (type png)
<use Censorship6b.png>
Package pdftex.def Info: Censorship6b.png used on input line 100.
(pdftex.def) Requested size: 401.50146pt x 119.6978pt.
<Censorship6.png, id=57, 638.385pt x 211.79124pt>
<Censorship6.png, id=59, 638.385pt x 211.79124pt>
File: Censorship6.png Graphic file (type png)
<use Censorship6.png>
Package pdftex.def Info: Censorship6.png used on input line 101.
(pdftex.def) Requested size: 401.50146pt x 133.20297pt.
<Censorship6c.png, id=58, 638.385pt x 211.79124pt>
<Censorship6c.png, id=60, 638.385pt x 211.79124pt>
File: Censorship6c.png Graphic file (type png)
<use Censorship6c.png>
@ -265,8 +264,8 @@ Overfull \hbox (11.50146pt too wide) in paragraph at lines 100--103
[]
[]
[11 <./Censorship6b.png> <./Censorship6.png>]
<Censorship6d.png, id=66, 638.385pt x 206.7725pt>
[11 <./Censorship6b.png> <./Censorship6.png> <./Censorship6c.png>]
<Censorship6d.png, id=67, 638.385pt x 206.7725pt>
File: Censorship6d.png Graphic file (type png)
<use Censorship6d.png>
Package pdftex.def Info: Censorship6d.png used on input line 108.
@ -276,8 +275,8 @@ Overfull \hbox (29.12628pt too wide) in paragraph at lines 108--109
[][]
[]
[12 <./Censorship6c.png> <./Censorship6d.png>] [13]
<Censorship7.png, id=81, 402.50375pt x 228.855pt>
[12 <./Censorship6d.png>] [13]
<Censorship7.png, id=82, 402.50375pt x 228.855pt>
File: Censorship7.png Graphic file (type png)
<use Censorship7.png>
Package pdftex.def Info: Censorship7.png used on input line 137.
@ -287,7 +286,7 @@ Overfull \hbox (29.12628pt too wide) in paragraph at lines 137--138
[][]
[]
[14] [15 <./Censorship7.png>] [16]
[14 <./Censorship7.png>] [15]
No file censorship_rejection.bbl.
LaTeX Font Info: Try loading font information for OMS+cmr on input line 157.
@ -326,7 +325,7 @@ Overfull \hbox (83.92566pt too wide) in paragraph at lines 161--162
FeltenWEIS2013.pdf
[]
[17] (./censorship_rejection.aux) )
[16] (./censorship_rejection.aux) )
Here is how much of TeX's memory you used:
1571 strings out of 494953
22794 string characters out of 6180977
@ -352,10 +351,10 @@ fonts/cm/cmsy8.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/c
m/cmti10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmti
12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmtt12.pfb
>
Output written on censorship_rejection.pdf (17 pages, 316546 bytes).
Output written on censorship_rejection.pdf (16 pages, 318848 bytes).
PDF statistics:
150 PDF objects out of 1000 (max. 8388607)
91 compressed objects within 1 object stream
147 PDF objects out of 1000 (max. 8388607)
89 compressed objects within 1 object stream
0 named destinations out of 1000 (max. 500000)
56 words of extra memory for PDF output out of 10000 (max. 10000000)

BIN
papers/censorship_rejection/censorship_rejection.pdf
View File

Binary file not shown.

10
papers/censorship_rejection/censorship_rejection.tex
View File

@ -28,13 +28,15 @@ Unlike invalid block attacks or finality reversion attacks, which can both be de
Most blockchain projects make no effort to even try to deal with the problem of majority coalition attacks such as censorship; an honest majority is usually one of the assumptions in any formal security proofs and models. Our goal is to see if we can go further.
One way to view what the strategies that we will explore is to see them as introducing non-censorship itself as a first-class consensus rule - that is to say, a block that does not include transactions that should have been included is invalid in the same way that a block that includes transactions that should not have been included (ie. invalid transactions) is invalid. As we will later see, this kind of consensus rule is fundamentally different from the other kinds of consensus rules that blockchain protocols tend to currently use, and we will look at the consequences that this introduces.
\section{Forgiving Rejection}
For simplicity, let us assume that there exists a simple Nakamoto-style blockchain, where consensus is determined by the longest chain rule.
\includegraphics[width=400px]{Censorship2.png}
Suppose further that there is only one type of transaction. This type of transaction requires a very large amount of proof of work to create, for anti-denial-of-service reasons, and we make the computational assumption that there does not exist enough computing power in the world to create more valid transactions than a single node can verify as part of the process of verifying a block (we are deliberately very generous with assumptions at first to illustrate the basic principle).
Suppose further that there is only one type of transaction. This type of transaction requires a very large amount of proof of work to create, for anti-denial-of-service reasons, and we make the computational assumption that there does not exist enough computing power in the world to create more valid transactions than a single node can verify as part of the process of verifying a single block (we are deliberately very generous with assumptions at first to illustrate the basic principle).
Now, let us modify the Nakamoto fork choice rule with an additional rule: if a node sees a transaction X for the first time at time T, then starting from time T + 168 hours, it will reject all chains that do not include X. We assume that transactions are always re-broadcasted, so that all honest clients and miners see all transactions (this is a reasonable assumption because it is already the case with blocks).
@ -43,7 +45,7 @@ Now, let us modify the Nakamoto fork choice rule with an additional rule: if a n
Notice that the primary guarantee of non-censorship is now met trivially. If a node sees a transaction X, then the blockchain that it accepts must, by definition, be a blockchain that includes X, at least after 168 hours. The harder claim to evaluate has to do with \textit{agreement}: that is to say, can we guarantee that a blockchain with miners running these rules will not permanently split?
Let us first suppose a synchrony assumption of one minute. Proof of work assumes a synchrony assumption implicitly, as if excessive network latency is permitted then it is quite easily possible for two chains to grow in parallel forever [cite 1], so this introduces no new assumptions. If this synchrony assumption applies both between miner and miner and between miner and client, then in the normal case no new risks are introduced: all miners will hear about all broadcasted transactions within one minute, miners include transactions immediately, and so analysis is identical to the standard Nakamoto case.
Let us first suppose a synchrony assumption of one minute. Proof of work assumes a synchrony assumption implicitly, as if excessive network latency is permitted then it is quite easily possible for two chains to grow in parallel forever [cite 1]; the main new assumption that we are introducing for the moment is that it's not just \textit{miners} that need to have low latency but also \textit{clients}. If this synchrony assumption applies both between miner and miner and between miner and client, then in the normal case no new risks are introduced: all miners will hear about all broadcasted transactions within one minute, miners include transactions immediately, and so analysis is identical to the standard Nakamoto case.
Now let us consider the possibility of \textit{temporary} 51\% attacks. Suppose that an extremely powerful miner broadcasts a block tree (that is, a chain or a diverging set of chains), and after this the miner's hashpower drops back to well below 51\%. For any given (block, transaction) pair, there is a maximum difference of two minutes in each client's perceived delay between the transaction and the block, and so it is very possible that some transaction was published (and seen by all clients) at time T, a chain not including that transaction published at time T + 168 hours - 30 seconds, with some clients perceiving the chain as having arrived before the 168 hour window and some clients perceiving the chain as having arrived after this window.
@ -71,9 +73,7 @@ But what happens if there \textit{is} a 51\% attack? By adding this unforgiving
This is a genuine disadvantage for the security of proof of work chains that adopt this feature, albeit a surmountable one. Without unforgiving rejection, a 51\% attack on a proof of work chain would need to be permanent in order to cause a permanent chain split. With unforgiving rejection, the a 51\% attack that lasts one week is enough. However, the difference between the economic capacity needed to maintain a 51\% attack for two weeks and the capacity needed to maintain one forever is not that large.
In proof of stake, the disadvantage is even smaller, as a 51\% attack triggered even once may by itself be enough to create a permanent chain split, so by adopting unforgiving rejection we appear to lose nothing.
Even though off-chain governance - that is, clients manually selecting the chain that they perceive as being the honest chain and rejecting the attacking chain, is thus required to resolve 51\% attacks in both proof of work and proof of stake, by introducing unforgiving rejection we gain a major advantage. Because the censorship rejection mechanism forces a chain split, a censoring 51\% attacker no longer wins ``cleanly'' by default. Without automated censorship rejection rejection, the community must actively coordinate to reject a censoring 51\% attack chain. With rejection, at least some clients reject the censoring chain, and so there is no longer the pressure of a default in the attacker's favor - instead, the community must choose between two options of equal status, except that one is an attacking chain and the other is not, and so it seems much more plausible that the losing chain will win.
In proof of stake, the disadvantage is even smaller, as a 51\% attack triggered even once may by itself be enough to create a permanent chain split, so by adopting unforgiving rejection we appear to lose nothing, and we gain the very substantial benefit that even a 51\% attack cannot cause clients to accept chains that are censoring.
\section{Incentives in the Uncoordinated Majority Model}