diff --git a/pdf/grandpa.pdf b/pdf/grandpa.pdf index e8ff943..4783839 100644 Binary files a/pdf/grandpa.pdf and b/pdf/grandpa.pdf differ diff --git a/pdf/grandpa.tex b/pdf/grandpa.tex index f1d304e..363bca0 100644 --- a/pdf/grandpa.tex +++ b/pdf/grandpa.tex @@ -34,7 +34,7 @@ Another popular consensus mechanism for blockchains is to get Byzantine agreemen The approach that we will take is similar to the approach that Ethereum plans to take with Casper the Friendly Finality Gadget(Casper FFG)\cite{CasperFFG}, which combines these approaches. We will use a block production mechanism and chain selection rule that give eventual consensus and then add a finality gadget, a protocol that finalises blocks that the participants already agree on, to get provable finality. -We present a finality gadget that works in a partially synchronous network model, GRANDPA, as well as an asynchronous finality gadget, that can cope with 1/5 Byzantine guys. +We present a finality gadget that works in a partially synchronous network model, GRANDPA, as well as an asynchronous finality gadget, that can cope with $1/5$ Byzantine guys. We seek to formalise the finality gadget problem and give a \subsection{Formalising the problem} @@ -50,9 +50,9 @@ We need to incorporate into the definition of Byzantine agreement that we have a \end{definition} -We cam change this definition to assume that instead of having an initial value, all voters have access to an external protocol, an oracle for values, that achieves eventual consensus in that it returns the same value to all voters when called after some time. +We can change this definition to assume that instead of having an initial value, all voters have access to an external protocol, an oracle for values, that achieves eventual consensus in that it returns the same value to all voters when called after some time. -\begin{definition} A protocol for multi-valued Byzantine finality gadget problem has a set of values $S$, a a set of voters $V$, a constant fraction of which may be Byzantine, each of whom has access to an oracle $A$ with the property that and in the end each voter decides a final value $f_v \in S$ such that the following holds: +\begin{definition} A protocol for multi-valued Byzantine finality gadget problem has a set of values $S$, a a set of voters $V$, a constant fraction of which may be Byzantine, each of whom has access to an oracle $A$ with the property that in the end each voter decides a final value $f_v \in S$ such that the following holds: \begin{itemize} \item {\bf Agreement:} All honest voters decide the same value for $f_v$ @@ -92,7 +92,9 @@ Lastly we are interested in the property of {\bf accountable safety}. This is th To come up with a solution to the blockchain Byzantine finality gadget problem, we will typically look at various Byzantine agreement protocols and use those to find protocols for the multi-valued Byzantine finality gadget problem. Protocols for that with appropriate properties can used to find protocols for the blockchain Byzantine finality gadget problem by considering running them in parallel at every block number. If the one block protocol has the right properties then they will agree on blocks consistently so if we finalise a block then we also finalise its ancestors and we can come up with a succinct protocol. -For example, suppose we have a one block protocol that calls for a vote on blocks which requires a participant to observe a supermajority, say votes from $2/3$ of voters, for some block (or else the participant observes that the vote is undecided). Now imagine running this vote in parallel for every block number and have any honest voter vote for blocks from a particular chain. Byzantine voters may vote more than once, but if we count a vote for a block as a vote for each ancestor of the block in the vote for the instance of the one block protocol with its number, then Byzantine voters must also vote for chains, though they can vote for multiple chains. If we do this, then we see that if a block has a supermajority in a vote, then so does all its ancestors in their votes. Thus the blocks with a supermajority form a chain. Furthermore, if only 1/3 of voters equivocate then from if a participant sees a subset of th votes for chains, then they must see a prefix of the chain of blocks that all the votes have supermajorities for. Intuitively, the protocol can agree on the prefix that 2/3 of voters agree on using this. +For example, suppose we have a one block protocol that calls for a vote on blocks which requires a participant to observe a supermajority, say votes from $2/3$ of voters, for some block (or else the participant observes that the vote is undecided). Now imagine running this vote in parallel for every block number and have any honest voter vote for blocks from a particular chain. Byzantine voters may vote more than once, but if we count a vote for a block as a vote for each ancestor of the block in the vote for the instance of the one block protocol with its number, then Byzantine voters must also vote for chains, though they can vote for multiple chains. If we do this, then we see that if a block has a supermajority in a vote, then so does all its ancestors in their votes. Thus the blocks with a supermajority form a chain. Furthermore, if only $1/3$ of voters equivocate then from if a participant sees a subset of the votes for chains, then they must see a prefix of the chain of blocks that all the votes have supermajorities for. Intuitively, the protocol can agree on the prefix that $2/3$ of voters agree on using this. + + @@ -103,15 +105,17 @@ For example, suppose we have a one block protocol that calls for a vote on block \section{Preliminaries} \label{sec:prelims} +{\bf Network model:} We will be mostly using a partially synchronous gossip network model, such as that described in \cite{Tendermint} II A. Participants communicate via a gossip network, where they are connected to a subset of other participants, and forward all messages they receive to all their connected peers. We assume that the network graph is such that any Byzantine participants are not able to cut of an honest participant and so any message sent or received by an honest participant reaches all honest participants. The partial synchrony we will use is the model where messages are received within time $T$, but possibly only after some Global Synchronisation Time{GST). Concretely, any message sent or received by some honest participant at time $t$ is received by all honest participants by time $\max{t,GST}+T$ at the latest. -We will want to change the set of participants who actively agree sometimes. To model this, we have a large set of participants who follow messages. For each voting step, there is a set of $n$ voters. We will frequently need to assume that for each such step, at most $f < n/3$ voters are faulty. We need $n-f$ of voters to agree on finality. Whether or not block producers ever vote, they will need to be participants who track the state of the protocol. +{\bf voters}: We will want to change the set of participants who actively agree sometimes. To model this, we have a large set of participants who follow messages. For each voting step, there is a set of $n$ voters. We will frequently need to assume that for each such step, at most $f < n/3$ voters are Byzantine. We need $n-f$ of voters to agree on finality. Whether or not block producers ever vote, they will need to be participants who track the state of the protocol. -Participants remember which block they see as currently being the latest finalised block and a chain they are locked to. This locked chain represents an estimate of which block could have been finalised already. +{\bf votes}: A vote is a block hash, together with some metadata such as round number and type of vote (prevote/precommit), all signed with a voter's private key. {\bf Rounds}: each participant has their own idea of what the current round number is. Every prevote and precommit has an associated round number. Honest voters only vote once (for each type of vote) in each round and don't vote in earlier rounds after later ones. -Each round has two phases, each of which has an associated vote, prevote and precommit. +Participants remember which block they see as currently being the latest finalised block and an estimate of which block could have been finalised in the last round. + @@ -124,7 +128,7 @@ Blocks are ordered as a tree with the genesis block as root. So any two blocks h A vote $v$ for a block $B$ by a validator $V$ is a message signed by $V$ containing the blockhash of $B$ and meta information like the round numbers and the type of vote. -We call a set $S$ of votes tolerant if the number of validators with more than one vote in $S$ is at most $f$. We say that $S$ has supermajority for a block $B$ if the set of validators with votes for blocks $\geq B$ has size at least $(n+f+1)/2$. +We call a set $S$ of votes tolerant if the number of voters with more than one vote in $S$ is at most $f$. We say that $S$ has supermajority for a block $B$ if the set of voters with votes for blocks $\geq B$ has size at least $(n+f+1)/2$. The $2/3$-GHOST function $g(S)$ takes a set $S$ of votes and returns the block $B$ with highest block number such that $S$ has a supermajority for $B$. If there is no such block, then it returns `nil`. (if $f \neq \lfloor (n-1)/3 \rfloor$, then this is a misnomer and we may change the name accordingly.) @@ -158,7 +162,7 @@ Note that it is possible for an intolerant $S$ to both have a supermajority for \end{itemize} \end{lemma} -\section{Algorithm} +\section{The GRANDPA protocol} We let $V_{r,v}$ and $C_{r,v}$ be the sets of prevotes and precommits respectively received by $v$ from round $r$ at the current time. @@ -189,7 +193,7 @@ and then broadcasts a precommit for $g(V_{r,v})$ {\em( (iii) is optional, we can }} -\subsection{ Finalisation} +\subsection{Finalisation} If, for some round $r$, at any point after the precommit step of round $r$, we have that $B=g(C_{r,v})$ is later than our last finalised block and $V_{r,v}$ has a supermajority, then we finalise $B$. 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).