Update on Overleaf.
This commit is contained in:
29
ccs-body.tex
29
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.
|
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}).
|
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.
|
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.
|
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é}
|
\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.
|
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.
|
We prove that the properties needed to maintain security of the protocol still hold in a dynamic context.
|
||||||
Our contributions are as follows:
|
Our contributions are as follows:
|
||||||
\begin{itemize}
|
\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 Modification of the protocol to account for said dynamicity.
|
||||||
\item Proof of properties in the dynamic context.
|
\item Proof of properties in the dynamic context.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
@@ -39,8 +39,7 @@ Our contributions are as follows:
|
|||||||
% Sensibly the same information that is in Mining in log space.
|
% Sensibly the same information that is in Mining in log space.
|
||||||
% Might add some context on dynamic environment?
|
% Might add some context on dynamic environment?
|
||||||
|
|
||||||
\subsection{Application state}
|
\paragraph{Application state}
|
||||||
|
|
||||||
Blockchain systems are designed to maintain an accurate 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.
|
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.
|
%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.
|
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.
|
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.
|
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.
|
%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.
|
%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.
|
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.
|
%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.
|
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}.
|
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.
|
We assume at least one of the provers is honest.
|
||||||
This is a standard assumption~\cite{garay2017bitcoin,garay2015bitcoin,heilman2015eclipse,wust2016ethereum,kiayias2021mining}
|
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.
|
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.
|
The verifier then needs to determine which NIPoPoW it receives is the right one.
|
||||||
|
|
||||||
\subsection{Consensus data}
|
|
||||||
|
|
||||||
|
\paragraph{Consensus data}
|
||||||
Application data has the potential to increase or decrease in size.
|
Application data has the potential to increase or decrease in size.
|
||||||
Accounts and smart contracts can be generated, removed, or modified.
|
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.
|
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
|
\par\bigskip
|
||||||
\begin{subfigure}[b]{\linewidth}
|
\begin{subfigure}[b]{\linewidth}
|
||||||
\includegraphics[width=1\linewidth]{figs/compressed.drawio.pdf}
|
\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}
|
\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}
|
\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.
|
%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.
|
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.
|
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.
|
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\).
|
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}.
|
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}$
|
\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.
|
% 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
|
% 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
|
% ñ definition page 172 Zindros thesis
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user