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 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}

ccs-template.tex

@@ -44,8 +44,11 @@
 \hidecommentfalse % comment to hide comments
 \newcommand\LM[1]{\ifhidecomment{}\else{\textcolor{blue}{LM: #1}}\fi}
 
+% Math
 \usepackage{ stmaryrd }
-\newtheorem{theorem}{Theorem}
+\newtheorem{theorem}{Theorem}[section]
+\newtheorem{corollary}{Corollary}[theorem]
+\newtheorem{lemma}[theorem]{Lemma}
 \newtheorem{definition}{Definition}
 
 %\fancyhf{} % Remove fancy page headers 
@@ -70,7 +73,7 @@
     Blockchain data is categorized into application data and consensus data, with consensus data growing unboundedly at a constant linear rate in time.
     Recently, a protocol to reduce storage and communication complexity of blockchains to $O(polylog(n))$ was proposed, but its security was only proven in a static context.
     
-    This paper focuses on modifying the protocol to fit a dynamic environment, with participants joining or leaving the network, and proving the upkeep of security properties in this context.
+    This paper focuses on modifying the protocol to fit a dynamic environment, with participants joining or leaving the network, and proving the conservation of security properties in this context.
     The contributions of this paper include a study of the protocol in the dynamic context, its modification, and proof of properties in the dynamic context.
 \end{abstract}
 
@@ -99,7 +102,7 @@
 
 \input{ccs-body} % TODO: replace with your brilliant paper!
 
-\bibliographystyle{plain}
+\bibliographystyle{IEEEtran}
 \bibliography{ccs-sample}
 
 \end{document}

properties.tex

@@ -1,24 +1,23 @@
 \begin{theorem}
     Le nombre de blocs de la partie stable dans le compressé n'est pas forcément une fonction croissante en la taille de la chaîne
 \end{theorem}
-
 \begin{proof}[Sketch]
     Procédons avec un contre-exemple ayant lieu avec une probabilité non-négligeable (supérieure à $\frac{1}{16}$). Cette probabilité vient du fait d'avoir après toute chaîne deux superblocs de niveau 0 puis un de niveau 1.\\
     Si on considère la chaîne \textit{simplifiée} présentée dans $figs/growth\_property.svg$:
+    % Note: je suis en train de finir les figures.
     \begin{itemize}
-        \item si on applique la compression jusqu'à la hauteur $n - 1$, on obtient le compressé présenté dans $figs/growth\_property_height_n_minus_1.svg$
+        \item si on applique la compression jusqu'à la hauteur $n - 1$, on obtient le compressé présenté dans \textit{figs/growth\_property\_height\_n\_minus\_1.svg}
         C'est-à-dire une partie stable de $q$ blocs distincts.
         
-        \item si on l'applique jusqu'à la hauteur $n$, on obtient le compressé présenté dans $figs/growth\_property_height_n.svg$
+        \item si on l'applique jusqu'à la hauteur $n$, on obtient le compressé présenté dans \textit{figs/growth\_property\_height\_n.svg}
         C'est-à-dire une partie stable de $q - 1$ blocs distincts.
     \end{itemize}
 \end{proof}
 
 
-\begin{theorem}
+\begin{theorem}\label{thm:block-level}
     Etant donné un compressé C de niveau l, l'ajout d'un bloc b à C donne C' de niveau $l' \geq l$
 \end{theorem}
-
 \begin{proof}[Sketch]
     Oui, par contruction, si le compressé est de niveau l on a au moins 2m blocs de niveau l.
     L'ajout d'un bloc de niveau l' < l ne change pas le nombre de blocs au niveau l dans le compressé qui reste de niveau l.
@@ -26,26 +25,28 @@
     Si l' > l, le compressé peut soit rester au niveau l car il n'y a pas au moins 2m blocs au niveau l', soit passer au niveau l'.
 \end{proof}
 
+\begin{corollary}
+    Le niveau  de la partie stable dans le compressé est une fonction croissante en la taille de la chaîne.
+\end{corollary}
+
 
 \begin{theorem}
     Si un bloc de niveau l est éjecté du niveau l, alors il n'est plus présent du tout dans le compressé.
 \end{theorem}
-
+\begin{proof}[Sketch]
-\begin{proof}
     Oui, par construction plus un bloc appartient aussi aux niveaux inférieurs plus la propriété précédente, pour éjecter un bloc de niveau l, il faut un bloc de niveau l' >= l.
 \end{proof}
 
 
 \begin{theorem}
-    Si un bloc de niveau l est présent dans un niveau l'<l, alors il est présent dans tous les niveaux intermédiaires entre l' et l
+    Si un bloc de niveau l est présent dans un niveau l'<l, alors il est présent dans tous les niveaux intermédiaires entre l' et l.
 \end{theorem}
-
+\begin{proof}[Sketch]
-\begin{proof}
     Oui, car virer un bloc au niveau l'', l' < l'' < l, nécessite un bloc de niveau >= l''. Comme il faut au moins 2m blocs par niveau, et qu'un bloc au niveau >= l'' compte aussi pour les niveaux inférieurs, il impacte de la même façon les niveaux inférieurs.
 \end{proof}
 
 
 \begin{theorem}
-    Pour un bloc b de niveau l, pour tout 0 <= i < j <= l, on a pos(i, b) <= pos(j, b)
+    Pour un bloc b de niveau l, pour tout $0 \le i < j \le l$, on a $pos(i, b) \le pos(j, b)$.
 \end{theorem}