diff --git a/ccs-body.tex b/ccs-body.tex
index 18434f0..6fa7330 100644
--- a/ccs-body.tex
+++ b/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 share the same starting point called {\em genesis block}.
+Each ordered collection shares the same starting point called {\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.
 
@@ -22,11 +22,11 @@ However, the security of their protocol was only proven in a static context~\cit
 \textcolor{blue}{On pourrait aussi évoquer flight client qui prennent en compte une difficulté variable mais qui nécessite de garder tous les blocks pour construire un résumé}
 
 In this paper, we focus on the aforementioned protocol.
-We modify it to fit a dynamic environment~\cite{garay2017bitcoin}, with participants joining or leaving the network.
+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 Study of the mining in logarithmic space protocol in the dynamic context.
+  \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}
@@ -39,8 +39,7 @@ Our contributions are as follows:
 % Sensibly the same information that is in Mining in log space.
 % Might add some context on dynamic environment?
 
-\subsection{Application state}
-
+\paragraph{Application state}
 Blockchain systems are designed to maintain an accurate application state.
 This state can be leveraged to determine important information such as who owns what and how much of it.
 %One of the key decisions in designing a blockchain system is determining how ownership should be represented.
@@ -66,7 +65,7 @@ The second school argues for storing both transactions and the state after these
 In such a system, the application state at the end of the blockchain does not need to be computed by applying the blocks.
 Instead, a block near the end of the chain can simply be inspected, and the application state within extracted.
 This can result in faster queries and simpler implementation of certain types of smart contracts.
-However, the downside is that the snapshot approach requires more storage space and can make synchronization of the network more complex.
+However, this approach requires more storage space and can make synchronization of the network more complex.
 
 %It is possible to apply either the transaction-only or snapshot approach to either UTXO-based or accounts-based ownership representations.
 %Bitcoin uses the UTXO-based representation and stores only transaction deltas, while Ethereum uses an accounts-based representation and stores snapshots.
@@ -77,17 +76,15 @@ However, the downside is that the snapshot approach requires more storage space
 For the rest of this paper, we work under the same assumption as Kiayias~\textit{et al.}~\cite{kiayias2021mining}, that is we assume a Proof of Work blockchain in which each block commits to an application state snapshot.
 %The representation of ownership is irrelevant for our purposes, and can either be UTXO-based or accounts-based.
 
-\subsection{Bootstrapping}
-
+\paragraph{Bootstrapping}
 A \emph{verifier} is a bootstrapping node wanting to synchronize with the rest of the network, booting for the first time and holding only the genesis block.
 This verifier receives NIPoPoWs from nodes already part of the network, which we call \emph{provers}.
 We assume at least one of the provers is honest.
 This is a standard assumption~\cite{garay2017bitcoin,garay2015bitcoin,heilman2015eclipse,wust2016ethereum,kiayias2021mining}
 Without loss of generality, this scenario can be reduced to just one honest prover and one adversarial prover.
-Then, the verifier needs to determine which NIPoPoW it receives is the right one.
-
-\subsection{Consensus data}
+The verifier then needs to determine which NIPoPoW it receives is the right one.
 
+\paragraph{Consensus data}
 Application data has the potential to increase or decrease in size.
 Accounts and smart contracts can be generated, removed, or modified.
 Conversely, consensus data expands steadily over time with the addition of blocks to the blockchain.
@@ -191,10 +188,10 @@ 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 compose 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.}
 \end{subfigure}
 
-\caption{\label{fig:compression} Kiayias~\textit{et al.}'s compression scheme~\cite{kiayias2021mining}pas.}
+\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. 
@@ -353,9 +350,9 @@ PoW systems rely on two functions, namely \diff{.} and \target{.}.
 
 Function \target{.} computes a value that depend on the current best blockchain to ensure a constant interblock delay.
 For instance, Bitcoin computes a new \target{.} at each sequence of 2016 blocks on the empirical interblock delay on the previous sequence.
-The adjustement of \target{.} output aims at handling the variation of the population of the system. 
+The adjustment of \target{.} output aims at handling the variation of the population of the system. 
 In case of a population growth, blocks are generated with a smaller interblock delay, \target{.} is thus lowered by the protocol.
-On the contrary, if the population decreases, the interblockdelay will increase and the \target{.} has to be increased by the protocol.
+On the contrary, if the population decreases, the interblock delay will increase and the \target{.} has to be increased by the protocol.
 
 Function \diff{b} computes a value that depend on the given block \(b\).
 In such a system, a block \(b\) is {\em valid} if \(b\) meets application specification, and if \diff{b} satisfies the current interblock delay condition, \emph{i.e.}, if the following condition holds \diff{b} \(\leq\) \target{b}.
@@ -538,7 +535,7 @@ For the common prefix to hold, we need $k \geq \frac{\theta \gamma m}{4 \tau}$.
     \item $\theta$: we have $f(T_r^{max}(E),n_r) \leq \theta f$ (with $f = 0.03$), so $\theta \geq \frac{f(T_r^{max}(E),n_r)}{f}$. As we can estimate $q$ as $\frac{diff(S)}{rounds(S)}$, with $S$ the number of blocks confirming the weather balloon, $diff(S)$ the expected number of nonces tested to mine the $S$ blocks and $rounds(S)$ the number of rounds occurring during the mining of the $S$ blocks. Then we have $\theta \geq \frac{1 - (1 - \frac{T}{2^\kappa})^{q n_r}}{f}$
     % Contrairement à ci-dessus où on prend une valeur assurant le pire cas, cela ne semble pas être le cas ci-dessous. \theta et \eta ont la même valeur... Donc il semble que l'on ai le même problème ci-dessus.
     % Page 2 Garay variable difficulty
-    \item $\gammadra$: by definition of $(\gamma, s)-respecting$, we have $\gamma \geq \frac{max_{r\in S}n_r}{min_{r \in S}n_r}$ with $n_r = \frac{diff(S)f 2^\kappa}{n_0 m T_0}$
+    %\item $\gammadra$: by definition of $(\gamma, s)-respecting$, we have $\gamma \geq \frac{max_{r\in S}n_r}{min_{r \in S}n_r}$ with $n_r = \frac{diff(S)f 2^\kappa}{n_0 m T_0}$
     % ñ definition page 172 Zindros thesis
 \end{itemize}