Skip to content

@misc{Pass_Seeman_Shelat_2016, plus elaboration on blockchain consensus security #63

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jamesray1 wants to merge 11 commits into
base: master
Choose a base branch
from
Open

@misc{Pass_Seeman_Shelat_2016, plus elaboration on blockchain consensus security #63

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
d229e12
@misc{Leonardos_2017,
jamesray1 Nov 17, 2017
d8999f4
@misc{Garay_Kiayias_Leonardos_2017,
jamesray1 Nov 17, 2017
aba489d
\cite{Garay_Kiayias_Leonardos_2017}
jamesray1 Nov 17, 2017
8cacda2
Pass_Seeman_Shelat_2016
jamesray1 Nov 24, 2017
1c9f75a
\cite{Garay_Kiayias_Leonardos_2017} + elaboration
jamesray1 Nov 24, 2017
48d4b5e
\cite{Pass_Seeman_Shelat_2016} instead of Garay
jamesray1 Dec 11, 2017
74fe41d
honeste > honest
jamesray1 Dec 11, 2017
c5c0426
Merge branch 'master' into patch-24
jamesray1 Dec 11, 2017
d68844a
missing }
jamesray1 Dec 11, 2017
2fb7fba
Another missing }
jamesray1 Dec 11, 2017
546dc48
\cite[pp.~4–5]{Pass_Seeman_Shelat_2016, pp.~4–5}
jamesray1 Dec 11, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion papers/CasperTFG/CasperTFG.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -83,7 +83,13 @@ \subsection{Comparing Traditional Consensus to Blockchain Consensus}

Blockchain consensus protocols like Bitcoin do not finalize/decide on one block at a time.\cite{nakamoto} In fact, the Bitcoin blockchain in particular does not make ``finalized decisions'' at all; blocks are ``orphaned'' if/when they are not in the highest total difficulty chain. \cite{orphanBitcoin} However, if the miners are able to mine on the same blockchain, then the blocks that get deep enough into the blockchain won't be reverted (``orphaned''). A block's depth in the blockchain therefore serves as a proxy for finalization. In the average case for blockchain consensus protocols, each node only requires approximately one message, $\mathcal{O}(1)$, for every block. \footnote{For Bitcoin, refer to \cite{nakamoto}, section 5 on pp. 3–4.}

Traditional consensus protocol research has focused on producing protocols that are asynchronously safe (i.e.\ blocks won't be reverted due to arbitrary timing of future events) and live in asynchrony (or partial synchrony) (i.e.\ nodes eventually decide on new blocks) \cite{Fischer_Lynch_Paterson_FLP_Impossibility_1985}. On the other hand, the Bitcoin blockchain is not safe in an asynchonous network but is safe and live (for unknown block-depth or ``confirmation count'') in a ``partially synchronous network''.
Traditional consensus protocol research has focused on producing protocols that are asynchronously safe (i.e.\ blocks won't be reverted due to arbitrary timing of future events) and live in asynchrony (or partial synchrony) (i.e.\ nodes eventually decide on new blocks). On the other hand, the Bitcoin blockchain is not safe in an asynchonous network but is safe and live (for unknown block-depth or ``confirmation count'') in a ``partially synchronous network''.\cite{Pass_Seeman_Shelat_2016} Specifically, the following properties are proven to be required for a blockchain to be safe (which Bitcoin is proven to satisfy), all with overwhelming probability (in $T$): \cite[pp.~4–5]{Pass_Seeman_Shelat_2016, pp.~4–5}
\begin{itemize}
\item \textit{consistency}: at any point, the chains of two honest players can differ only in the last $T$ blocks;
\item \textit{future self-consistence}: at any two points, $r$ and $s$, the chains of any honest player at $r$ and $s$ differ only within the last $T$ blocks;
\item \textit{g-chain growth}: at any point in the execution, the chain of honest players grows by at least $T$ blocks in the last $T/g$ rounds; where $g$ is called the chain-growth of the protocol.
\item \textit{\mu-chain quality}: for any $T$ consecutive blocks in any chain held by some honest player, the fraction of blocks that were "contributed by honest players" is at least \mu.
\end{itemize}

Traditional Byzantine fault tolerant consensus protocols have precisely stated Byzantine fault tolerance numbers (often they can tolerate less than a third of Byzantine faults, or up to $t$ faults when there are $3t + 1$ nodes)[CITE]. On the other hand, it is less clear exactly how many faults (measured as a proportion of hashrate) the Bitcoin blockchain protocol can tolerate.

Expand Down
18 changes: 18 additions & 0 deletions papers/CasperTFG/ethereum.bib
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,21 @@
@misc{Pass_Seeman_Shelat_2016,
title = {{Analysis of the Blockchain Protocol in Asynchronous Networks}},
author = "Rafael Pass and Lior Seeman and Abhi Shelat",
url = "https://eprint.iacr.org/2016/454.pdf",
year = "2016",
month = "September",
}

@misc{Garay_Kiayias_Leonardos_2017,
title = {{The Bitcoin Backbone Protocol: Analysis and Applications}},
author = "Juan A. Garay and Aggelos Kiayias and Nikos Leonardos",
url = "https://123doc.org/document/4286628-the-bitcoin-backbone-protocol.htm",
journal = "Proc. Eurocrypt 2015",
note = {{An abridged version of this paper appears in Proc. Eurocrypt 2015.}},
year = "2017",
month = "February",
}

@misc{orphanBitcoin,
title = {{Orphan Blocks}},
url = "https://bitcoin.org/en/developer-guide#orphan-blocks",
Expand Down