pezkuwichain/consensus
1
0
Fork 0
mirror of https://github.com/pezkuwichain/consensus.git synced 2026-04-22 02:07:56 +00:00
Code Issues Packages Projects Releases Wiki Activity

new introduction

Browse Source
This commit is contained in:
LefKok
2020-03-21 12:55:53 +01:00
parent 32734fc42a
commit b6e9dd70da
1 changed files with 18 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
pdf/grandpa.tex
+18 -15
View File
@@ -43,37 +43,40 @@
\section{Introduction}
Bitcoin~\cite{nakamoto09bitcoin} and its descendant~\cite{wood14ethereum} are cryptocurrencies that provide
Bitcoin~\cite{nakamoto09bitcoin} and its descendants~\cite{wood14ethereum,zcash} are cryptocurrencies that provide
secure automated value exchange without the need for a central managing authority.
In order to achieve this, they build on peer-to-peer networks where special nodes (usually called miners)
collect transactions from users and run a consensus protocol in order to maintain a distributed public ledger
usually termed as the \textit{blockchain}
One of the challenges of the Nakamoto consensus protocol run by these systems is that they only have the property of eventual consensus - that an ever growing prefix of the chain will be agreed upon by all participants forever onward. But this process generally takes tens of minutes and only gives probabilistic guarantees - if we see a few blocks building on a given block, we can estimate the probability that it is final.
known as the \textit{blockchain}.
One of the challenges of the consensus protocols run by these systems is that they only have the property of eventual consensus - that an ever growing prefix of the chain will be agreed upon by all participants forever onward. But this eventual consensus process generally takes tens of minutes and only gives probabilistic guarantees - if we see a few blocks building on a given block, we can estimate the probability that it is final.
Unfortunately these guarantees only hold if the underlying network is well-connected and the client able to find an uncensored source of information, two assumptions that
do not hold in Bitcoin~\cite{apostolaki17hijacking, gervais16tampering, hellman15eclipse}.
do not hold in adversarial environments~\cite{apostolaki17hijacking, gervais16tampering, hellman15eclipse}.
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 propose the complete opposite, to block liveness when finality is not readily achievable.
This can only happen if we change the existing infrastructure and provide hybrid BFT solutions, (byzcoin etc.), however it also has multiple shortcomings.
First, it is exclusive and leads to centralization as these protocols need to put a limit on the size of the group running the protocol 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.
New generation protocols~\cite{kokoris16enhancing,decker15bitcoin} 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.}
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, finality gadget can be deployed gradually and light clients can choose to consult them or follow the longest chain rule and ignore them, enabling light client heterogenity.
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.
Finally, the finality gadget are simpler than consensus protocols since they do not require complex and costly view change protocols
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.
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{kokoris18omniledger,zamani19rapidchain,kokoris18channels} 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.
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.
Instead , we introduce the GRANDPA finality gadget that works in a partially synchronous network model, in the presence f up to $1/3$ Byzantine actors. As a result the combination of GRANDPA with a classic block production mechanism like GHOST~\cite{xxx} 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.
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.
The combination of GRANDPA with a classic block production mechanism like GHOST~\cite{xxx} 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:
The rest of the paper is organized as follows:
%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.