Update on Overleaf.

ccs-body.tex

@@ -90,37 +90,6 @@ Consensus...
 
 
 
-\section{Related Work}\label{sec:related}
-The problem of blockchain becoming of considerable size was initially predicted by Satoshi Nakomoto 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. 
-
-Another approach to built 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. 
-
-Kiayias et al.~\cite{10.1007/978-3-662-53357-4_5} introduced and formalized an interactive proof mechanism, \emph{Proofs-of-Proof-of-Work} (PoPoW) based on superblocks that allows a client to verify a chain in sublinear time and communication complexity. However, the authors later showed the existence of an attack on the scheme and proposed a non-interactive  alternative (NIPoPoWs)~\cite{10.1145/3460120.3484784}. However, the proposed solution did not address the size of the blockchain that needed to be stored by any miner. The authors further used NIPoPoWs to develop a scheme that also allows the miners to operate in $O(\polylog(n))$ storage and communication complexity while reducing the security tolerance to a Byzantine adversary that controls strictly less than a third of the total computation power and limiting itself to operate in an environment with a fixed difficulty~\cite{10.1145/3460120.3484784}.
-
-The authors in~\cite{jain2022extending} propose a scheme to construct a succinct representation of the blockchain using NIPoPoWs that also operates in $O(\polylog(n))$ storage complexity and $O(\polylog(n))$ communication complexity and which  provably achieves security against a Byzantine adversary that controls strictly less than half of the total computational power.
-%
-The main idea of their solution is \emph{(i)} to  attach increasing weights $W_\beta(\ell)$ to the $\ell$-superblocks  where $\ell$ is above a given threshold $\beta$ (such superblocks are called  \emph{$\ell$-diamond} blocks), and \emph{(ii)}  to modify the chain selection rule so that the selected succinct chain is the one that accumulates the largest weight. With the modified chain selection rule, it is improbable for an attacker controlling less than half of the total hashing power to bias the honest sub-sample of the blockchain by suppressing these $\ell$-diamond blocks. The crucial point of their solution in terms of security is that an adversary cannot fake this set of diamond-blocks without actually providing work. Because the adversary has minority mining power, they cannot create a heavier sequence of diamond blocks  faster than the honest parties, for the same reason that an adversary cannot create a longer regular blockchain faster than the honest parties create one. Unfortunately, this solution also considers a fixed difficulty. 
-%Section~\ref{sec:background} talks about consensus and application data.
-
-\begin{table*}
-  \caption{Comparison to other works.}
-  \adjustbox{max width=\textwidth}{%
-    \centering
-    \begin{tabular}{cllllcccccr}
-      \toprule
-                                             & \textbf{BTC Full} & \textbf{BTC SPV}   & \textbf{Ethereum}    & \textbf{Superblock NIPoPows} & \textbf{FlyClient}           & \textbf{Mining in Log. Space} & This work \\
-      \midrule
-      \textbf{Prover storage}                & $n(c+\delta)$     & $nc + log(\delta)$ & $nc + k\delta + a$   & $nc + k\delta + a$           & $nc + k\delta + a$           & $\polylog(n)c + k\delta + a$  & ?         \\
-      \textbf{Communication}                 & $n(c+\delta)$     & $nc + log(\delta)$ & $nc + k\delta + a$   & $\polylog(n)c + k\delta + a$ & $\polylog(n)c + k\delta + a$ & $\polylog(n)c + k \delta + a$  & ?         \\
-      \textbf{Can verifier mine?}            & Yes               & No                 & Yes & No             & No                           & Yes                          & Yes?       \\
-      \textbf{Works in variable difficulty?} & Yes               & Yes                & Yes & No             & Yes                          & No                           & Yes?       \\
-      \bottomrule
-    \end{tabular}}
-  \label{tab:comp}
-\end{table*}
-
 \section{Model}
 
 We consider a large number of parties that will locally maintain and update their blockchain.
@@ -186,6 +155,10 @@ However, the adversary remains computationally bounded. Hence, it cannot, in a p
 % \]
 % Note that any valid block has a level at least \(k=0\), since we have \( \mathfrak{target}(b) -  \frac{\mathfrak{target}(b)}{2^0} = 0 \leq\) \diff{b} \(\leq\) \target{b}.
 
+
+
+
+
 \section{Properties of permissionless blockchains}\label{sec:background}
 
 We consider \emph{Proof-of-Work} based permissionless blockchains which achieve Nakamoto-based consensus~\cite{cryptoeprint:2014:765,10.5555/3002702} without relying on a trusted party by requesting the parties to contribute a limited resource such as hashing power. 
@@ -197,6 +170,47 @@ A robust blockchain protocol must ensure the following properties~\cite{cryptoep
     \textbf{Liveness} with parameters $u \in \mathbb{N}$: if all honest parties try to insert a valid transaction in their blockchain for $u$ consecutive rounds, the transaction shall be accepted by any honest party by the end of the last round of the set of $u$ rounds with overwhelming probability.
 %\end{itemize}
 
+
+
+
+
+\section{Related Work}\label{sec:related}
+The problem of blockchain becoming of considerable size was initially predicted by Satoshi Nakomoto 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. 
+
+Another approach to built 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. 
+
+Kiayias et al.~\cite{10.1007/978-3-662-53357-4_5} introduced and formalized an interactive proof mechanism, \emph{Proofs-of-Proof-of-Work} (PoPoW) based on superblocks that allows a client to verify a chain in sublinear time and communication complexity. However, the authors later showed the existence of an attack on the scheme and proposed a non-interactive  alternative (NIPoPoWs)~\cite{10.1145/3460120.3484784}. However, the proposed solution did not address the size of the blockchain that needed to be stored by any miner. The authors further used NIPoPoWs to develop a scheme that also allows the miners to operate in $O(\polylog(n))$ storage and communication complexity while reducing the security tolerance to a Byzantine adversary that controls strictly less than a third of the total computation power and limiting itself to operate in an environment with a fixed difficulty~\cite{10.1145/3460120.3484784}.
+
+The authors in~\cite{jain2022extending} propose a scheme to construct a succinct representation of the blockchain using NIPoPoWs that also operates in $O(\polylog(n))$ storage complexity and $O(\polylog(n))$ communication complexity and which  provably achieves security against a Byzantine adversary that controls strictly less than half of the total computational power.
+%
+The main idea of their solution is \emph{(i)} to  attach increasing weights $W_\beta(\ell)$ to the $\ell$-superblocks  where $\ell$ is above a given threshold $\beta$ (such superblocks are called  \emph{$\ell$-diamond} blocks), and \emph{(ii)}  to modify the chain selection rule so that the selected succinct chain is the one that accumulates the largest weight. With the modified chain selection rule, it is improbable for an attacker controlling less than half of the total hashing power to bias the honest sub-sample of the blockchain by suppressing these $\ell$-diamond blocks. The crucial point of their solution in terms of security is that an adversary cannot fake this set of diamond-blocks without actually providing work. Because the adversary has minority mining power, they cannot create a heavier sequence of diamond blocks  faster than the honest parties, for the same reason that an adversary cannot create a longer regular blockchain faster than the honest parties create one. Unfortunately, this solution also considers a fixed difficulty. 
+%Section~\ref{sec:background} talks about consensus and application data.
+
+\begin{table*}
+  \caption{Comparison to other works.}
+  \adjustbox{max width=\textwidth}{%
+    \centering
+    \begin{tabular}{cllllcccccr}
+      \toprule
+                                             & \textbf{BTC Full} & \textbf{BTC SPV}   & \textbf{Ethereum}    & \textbf{Superblock NIPoPows} & \textbf{FlyClient}           & \textbf{Mining in Log. Space} & This work \\
+      \midrule
+      \textbf{Prover storage}                & $n(c+\delta)$     & $nc + log(\delta)$ & $nc + k\delta + a$   & $nc + k\delta + a$           & $nc + k\delta + a$           & $\polylog(n)c + k\delta + a$  & ?         \\
+      \textbf{Communication}                 & $n(c+\delta)$     & $nc + log(\delta)$ & $nc + k\delta + a$   & $\polylog(n)c + k\delta + a$ & $\polylog(n)c + k\delta + a$ & $\polylog(n)c + k \delta + a$  & ?         \\
+      \textbf{Can verifier mine?}            & Yes               & No                 & Yes & No             & No                           & Yes                          & Yes?       \\
+      \textbf{Works in variable difficulty?} & Yes               & Yes                & Yes & No             & Yes                          & No                           & Yes?       \\
+      \bottomrule
+    \end{tabular}}
+  \label{tab:comp}
+\end{table*}
+
+
+
+
+
+
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{Non-Interactive~Proofs-of-Proof-of-Works}