Benjamin_Loison/Variable_MLS
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update on Overleaf.

Browse Source
This commit is contained in:
Benjamin Loison
2023-06-20 14:52:50 +00:00
committed by node
parent ca258973ea
commit 9506c421d3
3 changed files with 98 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files

55
ccs-body.tex
View File

@@ -18,11 +18,13 @@ 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 blockchains to $O(polylog(n))$.
However, the security of their protocol was only proven in a static context~\cite{garay2015bitcoin}, where the number of participants in the network is static.
\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é}
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 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.
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
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.
% 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}
@@ -32,14 +34,14 @@ Our contributions are as follows:
\end{itemize}
The remaining of this paper is organised as follows. XXXX
\section{Consensus and application data}\label{sec:background}
% Sensibly the same information that is in Mining in log space.
% Might add some context on dynamic environment?
\paragraph{Application state}
\subsection{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.
@@ -76,19 +78,19 @@ However, this approach requires more storage space and can make synchronization
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.
\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.
The verifier then needs to determine which NIPoPoW it receives is the right one.
\paragraph{Consensus data}
\subsection{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.
\subsection{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.
The verifier then needs to determine which NIPoPoW it receives is the right one.
@@ -163,6 +165,7 @@ However, the adversary remains computationally bounded. Hence, it cannot, in a p
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\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})]
@@ -172,10 +175,12 @@ A block that hashes to a value less than $T/(2^{\ell})$ is said to be a $\ell$-s
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}).
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:compression}). %The idea behind the NIPoPoW is that the security properties associated with the entire blockchain are also associated with superblocks at each level. Hence, the longest chain can be proven with only superblocks of the blockchain.
% \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. 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.
@@ -201,7 +206,6 @@ The proposal by Kiayias et al.~\cite{10.1145/3460120.3484784} offers the best-k
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
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}
@@ -226,15 +230,14 @@ Any scheme for operating and compressing blockchains requires to design (i) a \e
%\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.
\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}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{Compressed Chain Comparison Algorithm}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%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.
% \section{Mining in Logarithmic Space}
% Prior to presenting our scheme, we briefly describe Kiayias~\textit{et al.}' solution.