Update on Overleaf.

This commit is contained in:
2023-06-20 15:44:38 +00:00
committed by node
parent 9506c421d3
commit 046a7410ef

View File

@@ -21,8 +21,7 @@ Recently, Kiayias~\textit{et al.}~\cite{kiayias2021mining} have proposed a block
However, the security of their protocol was only proven if a fixed PoW difficulty is assumed for ll 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 ll 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 XX (un petit nom ??), a scheme to construct a succinct representation of the blockchain 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 In this work, we address this important issue and present XX (un petit nom ??), 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 handles a variable difficulty for the blocks of the blockchain. The main idea of our construction is to XXXXXXXX
handles a variable difficulty for the blocks of the blockchain. The main idea of our construction is to XXXXXXXX
% In this paper, we focus on the aforementioned protocol. % 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 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. We prove that the properties needed to maintain security of the protocol still hold in a dynamic context.
@@ -181,7 +180,7 @@ The key idea is to sub-sample the blocks in the blockchain such that the sub-sam
% \ea{You should explain why a constant and known number of superblocks convinces the verifier} % \ea{You should explain why a constant and known number of superblocks convinces the verifier}
% %
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, as illustrated in Figure~\ref{fig:compression}. Hence, the space and communication complexity of NIPoPoW is $O(\polylog(n))$. 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, as illustrated in Figure~\ref{fig:compression}. 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. 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 $c$ is the size of a block header, $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.
\begin{figure} \begin{figure}
@@ -232,12 +231,12 @@ Any scheme for operating and compressing blockchains requires to design (i) a \e
\subsubsection{Chain Compression Algorithm} \subsubsection{Chain Compression Algorithm}
The 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. %\sg{what is $\mu$ here?} %\ea{We should introduce the $\Pi$ notation here} The 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. %\sg{what is $\mu$ here?} %\ea{We should introduce the $\Pi$ notation here}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{Compressed Chain Comparison Algorithm} \subsubsection{Compressed Chain Comparison Algorithm}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%TODO: Give Intuition %TODO: Give Intuition
Let $\Pi_1, \Pi_2, \ldots, \Pi_n$ be the different compressed blockchains that a new party receives. The party first applies the compression algorithm to every compressed blockchain to make the comparison fair. 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. Let $\Pi_1, \Pi_2, \ldots, \Pi_n$ be the different compressed blockchains that a new party receives. The party first applies the compression algorithm to every compressed blockchain to make the comparison fair. 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} % \section{Mining in Logarithmic Space}
% Prior to presenting our scheme, we briefly describe Kiayias~\textit{et al.}' solution. % Prior to presenting our scheme, we briefly describe Kiayias~\textit{et al.}' solution.