diff --git a/ccs-body.tex b/ccs-body.tex
index b6c5695..27c7ce9 100644
--- a/ccs-body.tex
+++ b/ccs-body.tex
@@ -159,6 +159,105 @@ However, the adversary remains computationally bounded. Hence, it cannot, in a p
 
 
 
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\section{Non-Interactive~Proofs-of-Proof-of-Works}
+\label{sec:kiayias}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Intuition}
+ 
+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$.
+\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.
+
+
+{Non-Interactive Proofs-of-Proof-of-Works} ({NIPoPoWs}) compress a PoW-based blockchain  by subsampling its blocks~\cite{10.1007/978-3-662-53357-4_5}. The working principle behind this compression lies in the assumption that a sub-sample of the blocks, i.e., the $\ell$-superblocks,  can be sufficient to estimate the size of the original distribution of block headers~\cite{karantias2020compact,10.1145/3460120.3484784,10.1007/978-3-030-51280-4_27}. 
+The key idea is to sub-sample the blocks in the blockchain such that the sub-sampled chain represents the original chain; any difference in the original blockchain results in different sub-sampled blockchains. In more details, in a long enough  execution of a PoW blockchain, on average, $1/2^{\ell}$ of the blocks are $\ell$-superblocks. A NIPoPoW samples the $\ell$-superblocks to prove that the original blockchain contained $2^\ell$ blocks. In order to convince honest parties, the NIPoPoW contains a constant number $m$ of superblocks at each level (see Figure~\ref{fig:kiayias_diagram}). 
+%
+The scheme requires every block header to store pointers to the last superblock at every level in order to ensure that the subsampled blocks also form a valid chain. A chain of $n$ blocks will contain superblocks at $O(\log(n))$ levels. Hence, the space and communication complexity of NIPoPoW is $O(\polylog(n))$. 
+The proposal by Kiayias et al.~\cite{10.1145/3460120.3484784}  offers the best-known compression of PoW blockchains so far. It achieves  $O(\polylog(n)c + kd + a)$ storage and communication costs while allowing parties to mine new blocks based on this compressed blockchain, where $k$ is the common prefix parameter, $d$ is the size of application data per block, and $a$ is the size of application data. % in the blockchain. 
+
+
+%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}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+Any scheme for operating and compressing blockchains requires to design (i) a \emph{chain compression} algorithm and (ii) a \emph{compressed chain comparison} algorithm to determine which compressed chain to be retained in the case of forks. 
+
+%\begin{figure}
+%\centering
+% \begin{subfigure}{0.4\textwidth}
+%     \includegraphics[width=\textwidth]{S&P/figures/figure-1.pdf}
+%     \caption{The probabilistic hierarchical blockchain. Higher levels have achieved a higher difficulty during mining. All blocks are connected to the genesis block $G$.}
+%     \label{fig:first}
+% \end{subfigure}
+% \vfill
+% \begin{subfigure}{0.45\textwidth}
+%     \includegraphics[width=\textwidth]{S&P/figures/figure-2.pdf}
+%     \caption{View of the blockchain after compression at time $t$.}
+%     \label{fig:second}
+% \end{subfigure}
+% \vfill
+% \begin{subfigure}{0.45\textwidth}
+%     \includegraphics[width=\textwidth]{S&P/figures/figure-3.pdf}
+%     \caption{View of the same portion  of the blockchain at time $t' > t$, i.e., as time elapses, only $3$-superblocks are kept among the ``old" blocks of the blockchain.}
+%     \label{fig:third}
+% \end{subfigure}
+        
+%\caption{Illustration of Kiayias et al.'s~\cite{10.1145/3460120.3484784} compression scheme. }
+%\label{fig:kiayias_diagram}
+%\end{figure}
+
+
+
+\subsection{Chain Compression Algorithm}
+
+Kiayias et al.'s chain compression algorithm (from~\cite{10.1145/3460120.3484784}, Algorithm 1) 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. 
+
+
+\subsection{Compressed Chain Comparison Algorithm}
+
+
+Let $\Pi_1, \Pi_2, \ldots, \Pi_n$ be the different compressed blockchains that a new party receives. To compare any two compressed blockchains $\Pi$ and $\Pi'$, the compression algorithm selects the minimum level $\mu$ that contains a block present in both $\Pi$ and $\Pi'$. If no such block is found, it necessarily implies that the greatest level (compression level $\ell$) in the two compressed blockchains is not the same, and thus simply, the algorithm selects the one with the greatest level. If block $b$ is found in  both $\Pi$ and $\Pi'$ at the same level $\mu$, then the blockchain with the greatest number of blocks after $b$ wins the comparison. 
+
+
+% \section{Mining in Logarithmic Space}
+
+% Prior to presenting our scheme, we briefly describe Kiayias~\textit{et al.}' solution.
+% Kiayias~\textit{et al.}~\cite{kiayias2021mining} present a scheme to compress a blockchain, retaining only a poly-logarithmic number of blocks.
+% Such a scheme requires both a compression algorithm and a compressed chain comparison algorithm.
+% The former compresses a chain, while the latter allows a verifier bootstrapping to determine which compressed chain it must keep.
+% This scheme relies on the notion of superblocks.
+
+% \begin{definition}[$\mu$-superblock]
+%     Block satisfying the proof of work for a hash value $H(ctr||x||s) \leq \frac{T}{2^\mu}$.
+% \end{definition}
+
+% \subsection{Compression algorithm}
+
+% The compression algorithm is parameterized by a security (or inversely, compression) parameter $m$ and the common prefix parameter $k$~\cite{garay2015bitcoin}.
+% The chain is first separated into a stable and an unstable part.
+% The most recent $k$ blocks of the chain constitute the unstable part we call $\chi$, and set aside for now.
+% The stable part is then divided into levels, each level containing the set of superblocks of level $\mu$.
+% We keep all blocks from the highest level $\ell$ containing at least $2m$ superblocks.
+% For each level $\mu$ below $\ell$, we keep the last $2m$ blocks.
+% In addition, we keep all blocks after the $m^{th}$ block of level $\mu + 1$.
+% We call those blocks $\pi$.
+% The compressed chain $\Pi = \pi\chi$ constitutes an instance of the NIPoPoW proof.
+
+
+% \subsection{Comparison algorithm}
+
+\subsection{Properties}
+
+%\section{Variable difficulty setting}