From 3b81b9fabf7b7e8b8b340ded32a2b8a91ecf5fcd Mon Sep 17 00:00:00 2001 From: LefKok Date: Wed, 1 Apr 2020 17:43:56 +0200 Subject: [PATCH] cleaned --- pdf/grandpa.tex | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/pdf/grandpa.tex b/pdf/grandpa.tex index a2a9e83..48a1174 100644 --- a/pdf/grandpa.tex +++ b/pdf/grandpa.tex @@ -53,14 +53,14 @@ Unfortunately these guarantees only hold if the underlying network is well-conne do not hold in adversarial environments~\cite{apostolaki16hijacking, gervais15tampering, heilman15eclipse}. The underlying problem which enables these attacks is that first generation blockchain protocols do not consider finality (i.e., when will a block never be reverted) as a first class property, prioritizing liveness instead. -New generation protocols~\cite{kokoris16enhancing,decker16bitcoin} propose the complete opposite by employing a \emph{hybrid} approach~\cite{pass16hybrid}, to block liveness when finality is not readily achievable. -This can only happen if we change the existing infrastructure which has multiple shortcomings. -First, these hybrid consensus protocols are exclusive which might lead to centralization, because the protocol needs to put a limit on the number of participating miners in order to achieve good performance. -Second, tying consensus with liveness of the chain means that there is no optimism and blocks are committed only when all verification information are available.\xxx{Describe why this is a problem in the context of polkadot and other probabilistic protocols.} +New generation protocols~\cite{kokoris16enhancing,decker16bitcoin,pass16hybrid} propose the complete opposite, to forfeit liveness when finality is not readily achievable. +This can only happen if we change the existing infrastructure and has multiple additional shortcomings. +First, these ``hybrid'' consensus protocols are exclusive. The protocol needs to put a limit on the number of participating miners in order to achieve good performance, which might lead to centralization. +Second, tying consensus with liveness of the chain means that there is no optimism and blocks are committed only when all verification information are available.\xxx{Al:Describe why this is a problem in the context of polkadot and other probabilistic protocols.} In this work we show the that the middle ground also merits exploration. We introduce the idea of lazy finality which is encapsulated in the abstraction of a \emph{finality gadget.} -Separating the liveness of the consensus protocol from the finality of the blocks can have 4 concrete benefits for the overlying blockchain protocol. First, not every node that is competing to mine a block needs to be part of the finality gadget, hence we can get the \textit{best of both worlds} (i.e., full inclusive decentralization and scalable fast finality). Second we can reorganize \xxx{Al put a sentence on why this is a cool property.}. Third, a finality gadget can be deployed gradually and light clients can choose to consult it or follow the longest chain rule and ignore it, enabling light client heterogeneity. +Separating the liveness of the consensus protocol from the finality of the blocks can have four concrete benefits for the overlying blockchain protocol. First, not every node that is competing to mine a block needs to be part of the finality gadget, hence we can get the \textit{best of both worlds} (i.e., full inclusive decentralization and scalable fast finality). Second we can reorganize the chain for blocks that have not yet been finalized \xxx{Al put a sentence on why this is a cool property.}. Third, a finality gadget can be deployed gradually and light clients can choose to consult it or follow the longest chain rule and ignore it, enabling light client heterogeneity. The light client that trust the gadget do not need to have the full chain or actively listen to the network. This can in turn enable scalability~\cite{avarikioti19divide} in an ecosystem of multiple chains (weather sharding~\cite{kokoris17omniledger,al18chainspace,androulaki18channels} or heterogeneous~\cite{zamyatin19sok}), where no single party receives or stores all the data in the system. Finally, the finality gadget protocol is simpler than consensus protocols since they do not require a complex and costly view change phase. @@ -69,11 +69,19 @@ Finally, the finality gadget protocol is simpler than consensus protocols since More specifically, this work introduces the abstraction of a \emph{finality gadget} that runs along any block production mechanism (e.g., Nakamoto consensus) and provides provable finality guarantees instead of probabilistic. To this end we formalise the finality gadget problem and show that it is impossible to satisfy its properties with a deterministic asynchronous protocol. -To circumvent this impossibility result , we introduce the GRANDPA finality gadget that works in a partially synchronous network model, in the presence f up to $1/3$ Byzantine actors. +To circumvent this impossibility result , we introduce the GRANDPA finality gadget that works in a partially synchronous network model, in the presence of up to $1/3$ Byzantine actors. The combination of GRANDPA with a classic block production mechanism like GHOST~\cite{lewenberg15inclusive} results in the existing deployment of the polkadot network which provides fast finality under good network conditions and protects the clients without compromising the liveness when under attack. In our evaluation \xxx{add results} In summary we make the following contributions: +\begin{itemize} + +\item Introduce the idea of lazy finality and instiate it through a finality gadget abstraction + +\item Prove that BFG is impossible in asychrony and present GRANDPA + +\item Implement GRANDPA and evaluate it on the large scale network of a major blockchain system +\end{itemize} The rest of the paper is organized as follows: @@ -89,7 +97,7 @@ The rest of the paper is organized as follows: \section{Model, Definitions, and Impossibilities} -We want to formalise the notion of finality gadget to be a sub-protocol that can be deployed along any protocol providing with +We want to formalise the notion of finality gadget to be a sub-protocol that can be deployed along any protocol with eventual consensus and probabilistic finality and enhancing it with provable finality. To achieve this, we need to incorporate into the classic definition of Byzantine agreement the fact that we additionally have access to a protocol that would achieve eventual consensus if we did not affect it. @@ -133,6 +141,7 @@ This means that the extra information voters have here, that $A$ will eventually \paragraph{Proof:} +\xxx{TODO:Al} The asynchronous binary fault tolerant agreement problem is as follows: We have number of voters which each have an initial $v_i$ in $\{0,1\}$ @@ -325,9 +334,9 @@ Any honest voter only votes in round $r$ for chains containing their estimate $E } In order to find a solution to the finality gadget protocol we look in -consensus protocols that solve the stronger problem as described in the previous section. The key idea for our solution is to inherit the safety properties of a consensus protocol, but use the underlying blockchain as the driving force of liveness. This results in a protocol which does not block when for example the network is split. +consensus protocols that solve the stronger problem as described in the previous section. The key idea for our solution is to inherit the safety properties of a consensus protocol, but use the underlying blockchain as the driving force of liveness. This results in a protocol which does not stop when for example the network is split. Instead, only the finalization stops, but the blocks keep getting created and propagated to everyone. -This means that when the conditions are safe again, the finality gadget only needs to finalize the head of the chain\footnote{Which the oracle will return quickly to a supermajority of miner}, +This means that when the conditions are safe again, the finality gadget only needs to finalize the head of the chain\footnote{Which the oracle will return quickly to a supermajority of miners.}, instead of having to transmit and run consensus on every block. In Figure~\ref{fig:finality}, we analyze the differences between classic blockchain protocols~\cite{nakamoto08bitcoin,wood14ethereum}, finality gadget, and hybrid consensus solutions~\cite{kokoris16enhancing,gilad17algorand} \xxx{Experiment: Catchup 100s of blocks Hotstuff vs GRANDPA}. @@ -388,7 +397,6 @@ If, for some round $r$, at any point after the precommit step of round $r$, we h We may also send a commit message for $B$ that consists of $B$ and a set of precommits for blocks $\geq B$ (ideally for $B$ itself if possible see "Alternatives to the last blockhash" below). To avoid spam, we only send commit messages for $B$ if we have not receive any valid commit messages for $B$ and its descendants and we wait some time chosen uniformly at random from $[0,1]$ seconds or so before broadcasting. - If we receive a valid commit message for $B$ for round $r$, then it contains enough precommits to finalise $B$ itself if we haven't already done so, so we'll finalise $B$ as long as we are past the precommit step of round $r$. @@ -448,7 +456,7 @@ The first thing we want to show is asynchronous safety, assuming we have at most The challenge procedure works as follows: If $B$ and $B'$ are committed in the same round, then the union of their precommits must contain at least $f$ equivocations, so we are done. Otherwise, we may assume by symmetry that $B$ was committed in round $r$ and $B'$ in round $r' > r$. There are at least $n-f$ voters who precommitted $\geq B'$ or equivocated in round $r$ in their commit messages, so we ask those who precommitted $\geq B'$ why they did so. -Starting with $r''='$, we ask queries of the following form: +Starting with $r''=r' $, we ask queries of the following form: \begin{itemize} \item Why was $E_{r''-1} \not\geq B$ when you prevoted for or precommitted to $B'' \not\geq B$ in round $r'' > r$? \end{itemize}