diff --git a/pdf/grandpa.bib b/pdf/grandpa.bib index 52bc8ef..469d73a 100644 --- a/pdf/grandpa.bib +++ b/pdf/grandpa.bib @@ -24,4 +24,12 @@ journal={arXiv preprint arXiv:1807.04938}, year={2018}, url={https://arxiv.org/abs/1807.04938} +} + +@article{CasperCBC, + title={Casper the Friendly Ghost: A “Correct-by-Construction” Blockchain Consensus Protocol}, + author={Zamfir,Vlad}, + journal={}, + year={2017}, + url={https://github.com/ethereum/research/blob/master/papers/CasperTFG/CasperTFG.pdf} } \ No newline at end of file diff --git a/pdf/grandpa.pdf b/pdf/grandpa.pdf index 4783839..765d0d7 100644 Binary files a/pdf/grandpa.pdf and b/pdf/grandpa.pdf differ diff --git a/pdf/grandpa.tex b/pdf/grandpa.tex index 95684eb..ff2a383 100644 --- a/pdf/grandpa.tex +++ b/pdf/grandpa.tex @@ -26,19 +26,24 @@ \section{Introduction} -We consider the question of finality for blockchain protocols: when will a block be reverted. Many such protocols, such as the original blockchain, Bitcoin, have the property of eventual consensus - that an ever growing prefix of the chain will be agreed upon by all participants forever onward. But they generally only give probabilistic finality on a specific block - that under some assumptions about the network and participants, if we see a few blocks building on a given block, we can estimate the probability that it is final. +We consider the question of finality for blockchain protocols: when will a block be reverted. Many such protocols, such as the original blockchain, Bitcoin, have the property of eventual consensus - that an ever growing prefix of the chain will be agreed upon by all participants forever onward. +But they generally only give probabilistic finality on a specific block - that under some assumptions about the network and participants, if we see a few blocks building on a given block, we can estimate the probability that it is final. -But what we'd prefer is to have provable finality - for example a signed statement by a set of authorities, the set of whom ca be tracked, that the block is final. This is useful to prove what happened to light clients, who do not have the full chain or are not actively listening to the network, and to communicate with other chains, possibly as part of a scalability solution, whee not anyone receives or stores all the data in the system. +But what we'd prefer is to have provable finality - for example a signed statement by a set of authorities, the set of whom can be tracked, that the block is final. +This is useful to prove what happened to light clients, who do not have the full chain or are not actively listening to the network, and to communicate with other chains, possibly as part of a scalability solution, where not anyone receives or stores all the data in the system. -Another popular consensus mechanism for blockchains is to get Byzantine agreement on each block. This gives provable finality immediately. However this is slow if we have a large set of participants in the Byzantine agreement. +Another popular consensus mechanism for blockchains is to get Byzantine agreement on each block. +This gives provable finality immediately. However this is slow if we have a large set of participants in the Byzantine agreement. -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. +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 seek to formalise the finality gadget problem and give a +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 first seek to formalise the finality gadget problem. \subsection{Formalising the problem} -We need to incorporate into the definition of Byzantine agreement that we have access to a protocol that would achieve eventual consensus if we did not affect it. Consider a typical definition of multi-values Byzantine agreement. We have a set of participants $V$, most of which obey the protocol, but a constant fraction may be Byzantine i.e. behave arbitrarily +We need to incorporate into the definition of Byzantine agreement that we have access to a protocol that would achieve eventual consensus if we did not affect it. Consider a typical definition of multi-values Byzantine agreement. +We have a set of participants $V$, most of which obey the protocol, but a constant fraction may be Byzantine i.e. behave arbitrarily \begin{definition} A protocol for multi-valued Byzantine agreement has a set of values $S$, a set of voters $V$, a constant fraction of which may be Byzantine, each of whom start with an initial value $s_v \in S$ for each $v \in V$ and in the end each voter decides a final value $f_v \in S$ such that the following holds: @@ -63,7 +68,8 @@ We can change this definition to assume that instead of having an initial value, \end{definition} -Note that, in the case $|S| > 2$, this definition of validity is stronger than that the obvious generalisation for Multi-valued Byzantine agreement, that all honest voters decide a value with which some honest voter started. This is because this would be impossible if the fraction of Byzantine voters is bigger than $1/|S|$ as we cannot detect Byzantine voters who act like honest voters except for lying about their initial value so if fewer than $1/|S|$ voters act like they have some initial value, the protocol cannot know if any are honest. +Note that, in the case $|S| > 2$, this definition of validity is stronger than that the obvious generalisation for Multi-valued Byzantine agreement, that all honest voters decide a value with which some honest voter started with. +This is because that definition would be impossible if the fraction of Byzantine voters is bigger than $1/|S|$ as we cannot detect Byzantine voters who act like honest voters except for lying about their initial value so if fewer than $1/|S|$ voters act like they have some initial value, the protocol cannot know if any are honest. But for the case $|S|=2$, the two possible definitions of validity are equivalent. This means that we can reduce the binary version of the Byzantine finality gadget problem above to binary Byzantine agreement by each voter just calling $A$ at the start to obtain their initial value since if $A$ does not return the same value to every honest voter all the time then it returns both values to honest voters some times. Thus there are many existing algorithms for the binary Byzantine finality gadget problem. However the interesting problem in this case is whether the celebrated impossibility result of \cite{flp} generalizes to this finality gadget problem i.e. whether this oracle which is guaranteed to achieve eventual consensus makes it possible to have an asynchronous and deterministic protocol for agreement. A reduction is not immediately obvious. It turns out that the finality gadget version is indeed impossible see \ref{ssec:impossibility}. @@ -93,13 +99,32 @@ 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 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. +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. +To ensure safety, each participant maintains an estimate $E_r$ of the last block that could have been finalised in a round $r$. This has the property that in future rounds it overestimates the block that could have been finalised so that in round $r$, the chain with head $E_{r-1}$ contains all blocks that could have been finalised. Any honest voter only votes in round $r$ for chains containing their estimate $E_{r-1}$ and this guarantees that any block that could have been finalised in round $r-1$ will be finalised in round $r$. +\subsection{related work} +\subsubsection{Comparison with Casper} +The concept of finality gadget was introduced in Casper the friendly finality gadget and this remains the finality gadget which is most similar to ours. So it makes sense to compare these. However first, we should mention the other protocols that are also called Casper. +The first Casper was Casper TFG. Casper CBC\cite{CasperCBC} gives a recent and clearly specified version of this protocol. It's fork choice rule uses the GHOST selection rule on votes. In Casper TFG, votes are blocks, but they are counted by owner like votes, which different from how GHOST would be used with proof of work. It also has a flexible way of subjectively finalising blocks based on graphs of votes. +In Casper FFG\cite{CasperFFG}, validators vote on links between checkpoints, which occur at block numbers that are multiples of, say, 50. If there are 2/3 votes for one block at consecutive checkpoints, then we can finalise a chain of blocks up to the first checkpoint. + +Epochless Casper, + +Casper... + +There are two main differences between Casper FFG and GRANDPA. One is that in GRANDPA, different voters can cast votes simultaneously for blocks at different heights. + +The other main difference is how the finality gadget affects the fork-choice rule of the underlying block production mechanism. In GRANDPA, by default we will assume that this is only affected by having to include any finalised blocks. +\cite{CasperFFG} does not specify a fork-choice rule, but it requires that we build on justified blocks for liveness. Later specifications of Casper use the GHOST rule on votes for fork-choice. + +Only depending on finalised blocks gives a clearer separation between the block prduction mechanism and finality gadget. It may therefore be easier to adapt to other types of protocol that achieve eventual consensus - and there have been many diverse protocols that do this developed in the last few years. It also makes it far easier to prove liveness properties. If the finality gadget has not finalised anything and so does not interfere, then the underlying mechanism should reach eventual consensus, which should be enough for the finality gadget to finalise whatever we have consensus on. + +On the other hand, while building on the longest chain in the absence of a finality gadget to maximize block rewards may be rational if everyone else does, this is not always the case for building on the longest chain including the last finalised block. This is because it may be likely that a different chain is going to be finalised, in which case the rational thing to do might be to build on that. The GHOST on votes fork choice rule of ? and ? may be more rational. It is not clear that it is, nor is it clear how to prove liveness for such a rule. Further research may be needed to show that there is a fork choice rule which is rational and leads to liveness for the finality gadget.