diff --git a/ccs-body.tex b/ccs-body.tex index 56be8d0..66a1057 100644 --- a/ccs-body.tex +++ b/ccs-body.tex @@ -21,7 +21,7 @@ Recently, Kiayias~\textit{et al.}~\cite{kiayias2021mining} have proposed a block However, the security of their protocol was only proven if a fixed PoW difficulty is assumed for all blocks. This is not a realistic assumption in practice. For example the block difficulty in Bitcoin has shown exponential growth in the past decade. -In this work, we address this important issue and present XX (un petit nom ??), a scheme to construct a succinct representation of the blockchain using Non-Interactive Proofs-of-Proof-of-Works (NIPoPoWs) that also operates in $O(\polylog(n))$ storage complexity and $O(\polylog(n))$ communication complexity and handles a variable difficulty for the blocks of the blockchain. The main idea of our construction is to XXXXXXXX +In this work, we address this important issue and present for the first time a scheme to construct a succinct representation of the blockchain using Non-Interactive Proofs-of-Proof-of-Works (NIPoPoWs) that also operates in $O(\polylog(n))$ storage complexity and $O(\polylog(n))$ communication complexity and that handles chains with variable difficulty. The main idea of our construction is to XXXXXXXX. % In this paper, we focus on the aforementioned protocol. % We modify it to fit a variable difficulty setting~\cite{garay2017bitcoin}, with participants joining or leaving the network. We prove that the properties needed to maintain security of the protocol still hold in a dynamic context. @@ -194,14 +194,12 @@ The proposal by Kiayias et al.~\cite{10.1145/3460120.3484784} offers the best-k \par\bigskip \begin{subfigure}[b]{\linewidth} \includegraphics[width=1\linewidth]{figs/compressed.drawio.pdf} - \caption{Blockchain after compression. The proof $\Pi$ is composed of the stable $\pi$ and unstable $\chi$ parts.} + \caption{Blockchain after compression. The proof $\Pi$ is composed of the stable $\pi$ and unstable $\chi$ parts.\\$G$ and digits represent respectively the genesis block and the block levels.} \end{subfigure} \caption{\label{fig:compression} Kiayias~\textit{et al.}'s compression scheme~\cite{kiayias2021mining}.} \end{figure} -%However, their solution reduces the security of the protocol by guaranteeing resilience to only a third Byzantine adversary. Improving these security guarantees in NIPoPoW is the primary focus of the work. - \subsection{Algorithmic ingredients of the NIPoPoW} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -233,7 +231,8 @@ Any scheme for operating and compressing blockchains requires to design (i) a \e \subsubsection{Chain Compression Algorithm} -The Kiayias et al.'s chain compression algorithm (from~\cite{10.1145/3460120.3484784}, Algorithm~\ref{alg:chaincompression}) is parameterized by a security parameter $m$ and the common prefix parameter $k$. System parameter $m$ represents the number of blocks that a party wishes to receive to feel safe. The algorithm compresses the blockchain except for the $k$ most recent blocks, called \emph{unstable} blocks. The compression works as follows: for the highest level $\ell$ that contains more than $2m$ blocks, keep all the blocks but for every level $\mu$ below $\ell$, only keep the last $2m$ blocks and all the blocks after the $m^\text{th}$ block at the $\mu+1$ level. $\Pi$ is used to represent an instance of NIPoPoW proof. %\sg{what is $\mu$ here?} %\ea{We should introduce the $\Pi$ notation here} +The Kiayias et al.'s chain compression algorithm (from~\cite{10.1145/3460120.3484784}, Algorithm~\ref{alg:chaincompression}) is parameterized by a security parameter $m$ and the common prefix parameter $k$. System parameter $m$ represents the number of blocks that a party wishes to receive to feel safe. The algorithm compresses the blockchain except for the $k$ most recent blocks, called \emph{unstable} blocks. The compression works as follows: for the highest level $\ell$ that contains more than $2m$ blocks, keep all the blocks but for every level $\mu$ below $\ell$, only keep the last $2m$ blocks and all the blocks after the $m^\text{th}$ block at the $\mu+1$ level. $\Pi$ is used to represent an instance of NIPoPoW proof. + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \subsubsection{Compressed Chain Comparison Algorithm} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -290,7 +289,7 @@ A robust blockchain protocol must ensure the following properties~\cite{cryptoep \section{Related Work}\label{sec:related} The problem of blockchain becoming of considerable size was initially predicted by Satoshi Nakamoto in the original paper that introduced Bitcoin~\cite{nakamoto2008bitcoin}. He offered a simple solution of a \emph{Simplified Payment Verification (SPV)} that only requires a client to store the block headers and leave out transactions. Still the amount of data that needs to be downloaded from the network grows linearly with the size of the blockchain. An alternative would be for SPV clients to embed hardcoded checkpoints but that would introduce additional trust assumptions. -Flyclient~\cite{9152680} allows a succinct and secure construction of proofs in a setting with variable difficulty. They make use of Merkle mountain ranges to reference the whole previous blockchain from every block. If a full node has a proof and mines a new block on top of it, they cannot create a new proof without holding the whole chain. Thus logarithmic space mining is not possible with this scheme. CoinPrune~\cite{coinprune} still requires to store the entire chain of block header prior to to the pruning point. +Flyclient~\cite{9152680} allows a succinct and secure construction of proofs in a setting with variable difficulty. They make use of Merkle mountain ranges to reference the whole previous blockchain from every block. If a full node has a proof and mines a new block on top of it, they cannot create a new optimal proof without holding the whole chain. Thus logarithmic space mining is not possible with this scheme. CoinPrune~\cite{coinprune} still requires to store the entire chain of block header prior to to the pruning point. Another approach to build succinct proofs is to rely on SNARKS (for Succinct Non-Interactive Argument of Knowledge). Coda~\cite{coda2020} is such a construction. Coda compresses a chain to polylogarithmic size and updates the proof with new blocks. However, leveraging SNARKs requires a trusted setup for the common reference string. @@ -329,15 +328,16 @@ The main idea of their solution is \emph{(i)} to attach increasing weights $W_\ \item Link of $m$ related to $|epoch|$? \end{itemize} -The protocol described in Kiayias~\textit{et al.}~\cite{kiayias2021mining} works only in a constant difficulty setting. -That is, participants cannot join or leave the network, the number of participants is set from the start. -This entails a number of limitation rendering the protocol inoperative in the variable difficulty setting. -Firstly, the $\chi$ portion of the proof cannot be a constant number of blocks long. -Indeed, a low value for the common prefix parameter $k$ means the blockchain will potentially have a non-stable tip, sacrificing persistence. -A high value for $k$ means on the other hand that the tip will be too old, sacrificing liveness~\cite{zindros2020decentralized}. -The value for $k$ must correspond to \textit{sufficient work having been performed}~\cite{kiayias2021mining}. -The verifier must then first measure the difficulty of the network before comparing proofs. +The protocol described in Kiayias~\textit{et al.}~\cite{kiayias2021mining} holds for a static setting, that is for an environment in which the number of miners working for the construction of blocks is constant. Therefore PoWs are of fixed difficulty. +This is in contrast to the actual deployment of the Bitcoin blockchain where periodically, the difficulty is recalculated to cope with a variable and non predictable number of miners. + +In this paper we propose for the first time an implementation of the NiPoPoW with chains of variable difficulty. This requires to solve the following challenges. + +Firstly, the unstable part of the compressed chain (i.e., the $\chi$ part) cannot be a constant number of blocks long. Recall that in Kiayias~\textit{et al.}~\cite{kiayias2021mining}, $k$ represents this constant number of blocks. +Indeed, the unstable part must \textit{correspond to sufficient work having been performed}~\cite{kiayias2021mining}, this "sufficient work" being represented by the current difficulty. A wrong assessment of the length $k$ of the unstable part is highly undesirable. First, an underestimation of $k$ would be as detrimental for the security of the proof as the temporary presence of dishonest majority. Indeed, the adversary mining on top of the honest chain would first secretly append a block showing a manipulated snapshot (in favor of the adversary), then secretly would append $k$ blocks with valid transactions to its own $k+1$-th block, and finally would compress its secret chain with the honest one. Presenting such a proof to a verifier would be convincing as only the unstable part (i.e., the last $k$ blocks) are checked by the verifier~\cite{zindros2020decentralized}. Such an attack is successful either when the majority is dishonest (even temporary) or when the unstable part is not long enough, i.e., when $k$ is under-estimated. Now an over-estimation of $k$ would degrade the liveness property~\cite{zindros2020decentralized} ad the succinctness of the proof. + +Consequently, a correct estimation of $k$ is necessary tThus The verifier must then first measure the mining power of the network before comparing proofs. Another problem arising in the variable difficulty setting is that superblocks are only based on relative difficulties. In other words, superblocks only count the number of leading zeroes, and do not take into account the absolute difficulty of the block. @@ -345,7 +345,7 @@ This is not a problem in the constant difficulty setting, since every miner has However, this becomes a problem in the variable difficulty setting, since there is no longer a common target for all miners. This means the adversary can potentially mine on a chain with lower difficulty, obtaining rarer superblocks that on the honest chain, and ultimately being picked by the verifier over the honest chain. -Finally, the previous solution's compression algorithm does not account for a varying compression parameter. +Finally, the previous solution's compression algorithm does not account for a varying compression parameter $m$. Subsequent compressions with different value for $m$ can lose blocks that would have been included otherwise. Since one might need blocks that have been previously discarded, the Online property of Mining in Logarithmic Space is no longer valid in the variable difficulty setting. @@ -371,7 +371,7 @@ In order to validate our assumptions on \hash{.}, and thus on \diff{.} and \targ \begin{figure} \includegraphics[width=\linewidth]{figs/distribution_ratio.pdf} -\caption{\label{fig:ratio} Ratio of \diff{.} of \target{.} of Bitcoin's blockchain.} +\caption{\label{fig:ratio} Ratio of \diff{.} of \target{.} of Bitcoin's blockchain in ascending order.} \end{figure} Finally, we refer by \level{.} the level function defined as follows~: @@ -397,7 +397,7 @@ We note $\mathcal{C}$ an interlinked blockchain, with $\mathcal{C}[i]$ denoting $\mathcal{C}[i:j]$ represents blocks from the $i^{th}$ element inclusive to the $j^{th}$ block exclusive. $\mathcal{C}[:j]$ denotes blocks from the start up to the $j^{th}$ block exclusive, and $\mathcal{C}[i:]$ denotes blocks from the $i^{th}$ element inclusive to the end of the chain. Block indices $i$ and $j$ can be replaced by blocks $A$ and $Z$. -We then write $\mathcal{C}[A:Z]$ to designate the chain from block $A$ inclusive to $Z$ exclusive. +We then write $\mathcal{C}\{A:Z\}$ to designate the chain from block $A$ inclusive to $Z$ exclusive. Again, any end can be omitted. A negative index means to take blocks from the end instead of from the start, thus $\mathcal{C}[-1]$ denotes the tip of $\mathcal{C}$. @@ -486,10 +486,10 @@ The remaining $\mathcal{C}[:-k]$ constitutes our stable part of the chain. We consider a node booting for the first time, holding only the genesis block. This node is parameterized by the security parameter $m$. We call this node a verifier. -The first step of the verifier is to gauge the current difficulty of the network. +The first step of the verifier is to gauge the current mining power of the network. Indeed, the verifier needs to determine a value for $k$ to know the length of the unstable parts of the NIPoPoWs it will receive. The verifier cannot just receive this value from the provers, as there is no way it can then determine the correct value for $k$ among the ones it receives. -The verifier can determine a value for $k$ by gauging the current difficulty of the network. +The verifier can determine a value for $k$ by gauging the current mining power of the network. We use the idea of a weather balloon to do so~\cite{zindros2020decentralized}. Once the verifier has determined a value for $k$, it will connect to multiple full nodes, which we call provers. diff --git a/ccs-sample.bib b/ccs-sample.bib index 90bc26d..b153900 100644 --- a/ccs-sample.bib +++ b/ccs-sample.bib @@ -32,6 +32,16 @@ organization={Springer} } +@inproceedings{AM2017, + title={The blockchain consensus layer and BFT}, + author={I. Abraham and D. Malkhi}, + booktitle={Bulletin of the EATCS}, + % https://people.irisa.fr/Emmanuelle.Anceaume/Manuscript.pdf#page=43 + %pages={291--323}, + % 3(123):1–23 + year={2017} +} + @phdthesis{zindros2020decentralized, title={Decentralized Blockchain Interoperability}, author={Zindros, Dionysis}, @@ -230,3 +240,14 @@ address="Cham", pages="505--522", isbn="978-3-030-51280-4" } + +@book{10.5555/3002702, +author = {Wattenhofer, Roger}, +title = {The Science of the Blockchain}, +year = {2016}, +isbn = {1522751831}, +publisher = {CreateSpace Independent Publishing Platform}, +address = {North Charleston, SC, USA}, +edition = {1st}, +abstract = {FinTech developers and managers understand that the blockchain has the potential to disrupt the financial world. The blockchain allows the participants of a distributed system to agree on a common view of the system, to track changes in the system, in a reliable way. In the distributed systems community, agreement techniques have been known long before cryptocurrencies such as Bitcoin (where the term blockchain is borrowed) emerged. Various concepts and protocols exist, each with its own advantages and disadvantages. This book introduces the basic techniques when building fault-tolerant distributed systems, in a scientific way. We will present different protocols and algorithms that allow for fault-tolerant operation, and we will discuss practical systems that implement these techniques.} +} \ No newline at end of file