Update on Overleaf.

ccs-body.tex

@@ -7,7 +7,7 @@ This lack of scalability limits the adoption of blockchain technology and hinder
 
 A blockchain refers to a set of ordered collection of blocks that are {\em valid} with respect to the application specifications. 
 Note that some blockchain designs require a total order (\emph{e.g.}, Bitcoin~\cite{nakamoto2008bitcoin} or Ethereum) while some other don't (\emph{e.g.} Avalanche~\cite{rocket2020scalable}, Byteball~\cite{byteball}, Sycomore~\cite{AGLS18}).
-Each ordered collection shares the same starting point called {\em genesis block}.
+Each ordered collection shares the same starting point called the {\em genesis block}.
 Each blockchain has a deterministic criteria to determine the {\em best} ordered collection of blocks.
 In the following, we will consider a totally ordered sequence of blocks, and the best collection refers to the longest chain starting from the genesis block.
 
@@ -18,29 +18,32 @@ Everything that is part of the block header is considered consensus data.
 
 While application data can grow or shrink depending on the implementation, consensus data grows boundlessly at a constant linear rate in time~\cite{kiayias2021mining}.
 Recently, Kiayias~\textit{et al.}~\cite{kiayias2021mining} have proposed a blockchain protocol to reduce storage and communication complexity of PoW blockchains to $O(polylog(n))$.
-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. 
+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 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 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-Work (NIPoPoWs) that also operates in $O(\polylog(n))$ storage and communication complexity, and that handles chains of 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.
 Our contributions are as follows:
 \begin{itemize}
-\item We propose XX, a NIPoPoW protocol that handles a variable PoW difficulty for blocks while operating in $O(\polylog(n))$ storage complexity and $O(\polylog(n))$ communication complexity;
-\item We present experimental results illustrating the compression of Bitcoin. 
+\item We propose XX, a NIPoPoW protocol that handles a variable PoW difficulty for blocks while operating in $O(\polylog(n))$ storage and communication complexity;
+\item We present experimental results illustrating the compression of Bitcoin.
 %  \item Study of the Mining in Logarithmic Space protocol in the variable difficulty setting.
   %\item Modification of the protocol to account for said dynamicity.
  % \item Proof of properties in the dynamic context.
 \end{itemize}
 
+The remaining of this paper is organised as follows.
+XXXX
 
-The remaining of this paper is organised as follows. XXXX
 
 
 \section{Consensus and application data}\label{sec:agreement}
-% Sensibly the same information that is in Mining in log space.
-% Might add some context on dynamic environment?
 
 \subsection{Application state}
 Blockchain systems are designed to maintain an accurate application state.
@@ -99,7 +102,7 @@ The verifier then needs to determine which NIPoPoW it receives is the right one.
 \section{Model}
 
 We consider a large number of parties that will locally maintain and update their blockchain.
-The system is considered as open, meaning that parties  may join and leave the system whenever they want without any admission control.
+The system is considered open, meaning that parties  may join and leave the system whenever they want without any admission control.
 
 %In order to consistently update their local blockchains, participants have to agree on the next block to append to their blockchain.
 %Various strategies to achieve this goal exist. 
@@ -170,7 +173,7 @@ However, the adversary remains computationally bounded. Hence, it cannot, in a p
 The proof-of-work system requires each party to generate a ``proof" of investment of a limited resource such as hash power, which takes time to generate but can be quickly verified by other parties. 
 Every party that wants to append a block to the blockchain is required to provide a \emph{nonce} along with the contents of the block, that hashes to a value below a given target. The hash function $\mathcal{H}$ is modelled as a random oracle~\cite{random-oracle}, i.e., behaves likes an ideal random function, and produces constant length output. Since the distribution of hash values is stochastic, some blocks end up with hash values significantly below the target. 
 \begin{definition}[$\ell$-superblock (\cite{10.1145/3460120.3484784})]
-A block that hashes to a value less than $T/(2^{\ell})$ is said to be a $\ell$-superblock, where $T$ is the current target value and $\ell \geq 1$.
+A block that hashes to a value less than $T/(2^{\ell})$ is said to be a $\ell$-superblock, where $T$ is the current target value and $\ell \geq 0$.
 \end{definition}
 
 Note that every $\ell$-superblock  is also a $\ell'$-superblock for any  $\ell' \leq \ell$ and the genesis block is considered to have a hash value of $\texttt{0x00}\ldots\texttt{0}$ and hence, is a superblock of the highest level.
@@ -231,7 +234,7 @@ 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. 
+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}