mirror of
https://github.com/pezkuwichain/consensus.git
synced 2026-04-22 07:58:05 +00:00
Minor changes to grandpa
This commit is contained in:
Binary file not shown.
+6
-7
@@ -37,8 +37,7 @@
|
||||
|
||||
\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 never 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 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.
|
||||
@@ -49,7 +48,7 @@ This gives provable finality immediately. However this is slow if we have a larg
|
||||
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 nodes.
|
||||
We present a finality gadget that works in a partially synchronous network model, GRANDPA, that works in the presence f up to $1/3$ Byzantine actors as well as an asynchronous finality gadget, that can cope with $1/5$ Byzantine actors.
|
||||
|
||||
Recent research on consensus has come up with many different block production mechanisms that give eventual consensus. We want formal guarantees to hold for finality gadgets that can easily be applied to many possible block production mechanisms. Thus we want to make the least assumptions about the block production mechanism as possible.
|
||||
|
||||
@@ -91,7 +90,7 @@ We say an oracle $A$ in a protocol is {\em eventually consistent} if it returns
|
||||
|
||||
For the binary case, i.e. when $|S|=2$, the Byzantine finality gadget problem is reducible to Byzantine agreement. This does not hold for $|S| > 2$, because the definition of validity is stronger. Note that it is impossible for multi-valued Byzantine agreement to make the validity condition require that we decide an initial value of some honest voter and tolerate more than a $1/|S|$ fraction of faults, since we may have a $1/|S|$ fraction of voters reporting each inital value and Byzantine voters can act honestly enough not to be detectable. For finality gadgets, this stronger validity condition is possible and we will want even stronger versions that quantify when an honest voter had the value.
|
||||
|
||||
We show in \ref{ssec:impossibility} that an asynchronous, deterministic binary finality gadget is impossible, even with one fault. This does not immediately follow from the celebrated impossibility result of \cite{flp} because we do not know a reduction in the necessary direction, from agreement to the finality gadget problem. The extra information voters have here, that $A$ will evntually agree for all voters, is not enough to make this possible.
|
||||
We show in \ref{ssec:impossibility} that an asynchronous, deterministic binary finality gadget is impossible, even with one fault. This does not immediately follow from the celebrated impossibility result of \cite{flp}, which shows that an asynchronous, deterministic binary Byzantine agreeement protocol is impossible, because we do not know a reduction in the necessary direction, from agreement to the finality gadget problem. The extra information voters have here, that $A$ will evntually agree for all voters, is not enough to make this possible.
|
||||
|
||||
|
||||
Now how do we extend this to agreeing on a chain of blocks? One difficulty in formalising the problem is that the block production mechanism cannot be entirely separate from the finality gadget. In order to finalise new blocks, we must first build on the chain we have already finalised. So at a minimum, the block production mechanism needs to recognise which blocks the finality gadget has finalised. We will also allow the block production mechanism to interact with the state of the finality gadget in other ways.
|
||||
@@ -104,7 +103,7 @@ We also want a protocol that does not terminate, but instead keeps on finalising
|
||||
We assume that there is a block production protocol $P$ that runs at the same time as the finality gadget protocol $G$. Actors who are participants in both protocols may behave differently in $P$ depending on what happened in $G$.
|
||||
However in the reverse direction, the only way that an honest voter $v$'s behaviour in $G$ is affected by $P$ is through a voting rule, a function $A(v,s_v,B)$ that depends on $v$ and its state $s_v$ and takes a block $B$ and returns a block $B'$ at the head of a chain including $B$.
|
||||
|
||||
We say that the system $G$,$P$ and $A$ achieves conditional eventual consensus, if $G$ has finalised a block $B$, then eventually, either $G$ will finalise some descendant of $B$ or else all the chains with head $A_{v,s_v}(B)$ for all voters $v$ at all future states $s_v$ will contain the same descendant $B'$ of $B$.
|
||||
We say that the system $G$,$P$ and $A$ achieves {\em conditional eventual consensus}, if $G$ has finalised a block $B$, then eventually, either $G$ will finalise some descendant of $B$ or else all the chains with head $A_{v,s_v}(B)$ for all voters $v$ at all future states $s_v$ will contain the same descendant $B'$ of $B$.
|
||||
|
||||
\begin{definition} \label{def:finality-gadget}
|
||||
Let $F$ be a protocol with a set of voters $V$, a constant fraction of which may be Byzantine.
|
||||
@@ -263,7 +262,7 @@ Note that it is possible for an intolerant $S$ to both have a supermajority for
|
||||
\end{itemize}
|
||||
\end{lemma}
|
||||
|
||||
\section{The GRANDPA protocol}
|
||||
\section{The GRANDPA protocol} \label{sec:grandpa}
|
||||
|
||||
In this section, we give the protocol for GRANDPA, our finality gadget in the partially synchronous setting.
|
||||
|
||||
@@ -811,7 +810,7 @@ Crucially note that $h$ depends only on $S$, which is determined when $4f+1$ vot
|
||||
\end{enumerate}
|
||||
}}
|
||||
|
||||
We claim that all results we proved about the protocol described in section ? apply to this protocol. the stronger properties this satisifies are that $v$ does not need to store votes from before round $r-1$ (except to answer challenges for accountable safety, which should be rare) and that if we have seen no descendants of the last finalised block, we pause until we do.
|
||||
We claim that all results we proved about the protocol described in Section \ref{sec:grandpa} apply to this protocol. the stronger properties this satisifies are that $v$ does not need to store votes from before round $r-1$ (except to answer challenges for accountable safety, which should be rare) and that if we have seen no descendants of the last finalised block, we pause until we do.
|
||||
|
||||
|
||||
\bibliography{grandpa}
|
||||
|
||||
Reference in New Issue
Block a user