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:
loic.miller
2023-06-19 16:36:19 +00:00
committed by node
parent 732b162ee7
commit 103e19c6b7
4 changed files with 49 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files

95
ccs-body.tex
View File

@@ -43,18 +43,18 @@ Our contributions are as follows:
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.
There are two primary ways of doing so: UTXO-based and accounts-based systems.
In UTXO-based systems, the application state is comprised of the unspent transaction outputs that are available for spending.
On the other hand, in accounts-based systems, the application state is comprised of accounts and balances.
Notably, Bitcoin uses the UTXO-based approach to maintain its application state, while Ethereum uses an accounts-based system.
The application state of a blockchain system is in a constant state of evolution as new transactions are applied to it.
Each transaction acts as a state evolution operator, making changes to the current state of the system.
In essence, a transaction represents a set of instructions that dictate how the application state should be transformed.
By applying a transaction to a previous application state, a new application state can be computed.
This new state reflects the changes introduced by the transaction, such as the transfer of ownership of assets or the execution of a smart contract.
%One of the key decisions in designing a blockchain system is determining how ownership should be represented.
%There are two primary ways of doing so: UTXO-based and accounts-based systems.
%In UTXO-based systems, the application state is comprised of the unspent transaction outputs that are available for spending.
%On the other hand, in accounts-based systems, the application state is comprised of accounts and balances.
%Notably, Bitcoin uses the UTXO-based approach to maintain its application state, while Ethereum uses an accounts-based system.
%
%The application state of a blockchain system is in a constant state of evolution as new transactions are applied to it.
%Each transaction acts as a state evolution operator, making changes to the current state of the system.
%In essence, a transaction represents a set of instructions that dictate how the application state should be transformed.
%By applying a transaction to a previous application state, a new application state can be computed.
%This new state reflects the changes introduced by the transaction, such as the transfer of ownership of assets or the execution of a smart contract.
%
Each block in a blockchain system represents a batch of transactions that are processed in a particular sequence.
By processing these transactions in a specific order, the block acts as a state evolution operator that updates the overall application state of the system.
@@ -68,23 +68,29 @@ Instead, a block near the end of the chain can simply be inspected, and the appl
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.
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 could potentially commit the newly computed unspent transaction output (UTXO) in every block, and some Bitcoin forks have already implemented this feature.
On the other hand, Ethereum maintains both deltas and snapshots in its blocks.
While snapshots are not necessary, they are incredibly helpful in ensuring the integrity and efficiency of the blockchain.
%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 could potentially commit the newly computed unspent transaction output (UTXO) in every block, and some Bitcoin forks have already implemented this feature.
%On the other hand, Ethereum maintains both deltas and snapshots in its blocks.
%While snapshots are not necessary, they are incredibly helpful in ensuring the integrity and efficiency of the blockchain.
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}
A bootstrapping node is a 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}.
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.
Then, the verifier needs to determine which NIPoPoW it receives is the right one.
\subsection{Consensus data}
Consensus...
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.
@@ -99,11 +105,8 @@ The system is considered as open, meaning that parties may join and leave the s
%Various strategies to achieve this goal exist.
%In the following, we will consider Proof-of-Work~\cite{Back02hashcash} (PoW) strategy.
We consider a \emph{synchronous} setting where time is quantized into discrete rounds~\cite{cryptoeprint:2014:765,10.1145/3460120.3484784}, during which every party can send a message to each of its neighbours, receive the messages sent to it during the round, and execute computational steps based on the received messages. Note that computational steps other than hashing are treated as instantaneous. %This reflects a \emph{synchronous} network.
We assume the presence of a Byzantine or malicious adversary that may control strictly less than half of the total amount of computational power currently available in the system. This model, named the "Computational Threshold Adversary"~\cite{AM2017}, is an alternative to the Common Threshold Adversary Model, which bounds the total number of parties the adversary controls relative to the total population of the system. Specifically, each party is allowed to make $q$ queries to a cryptographic hash function in every round.
The adversary controls up to $t$ parties.
For this reason, the adversary can query the cryptographic hash function up to $t \times q$ times per round~\cite{cryptoeprint:2014:765}.
@@ -120,8 +123,6 @@ However, the adversary remains computationally bounded. Hence, it cannot, in a p
% Second, we assume that \hash{.} values are uniformly distributed over the \(\llbracket 0 ; 2^{\ell} -1\rrbracket \)interval.
% Finally, we assume that \hash{.} is collision free in the sense that given two blocks \(b_1, b_2\) we have \(b_1 = b_2 \Leftrightarrow \) \hash{b_1} = \hash{b_2}.
% \textcolor{blue}{je ne suis pas completement sure que la suite fasse partie du modele. En fait il faut mettre toute cette partie là ou on va expliquer notre solution}
% In addition to the application specifications, a block \(b\) is valid if it can be appended to a prefix of the current blockchain.
% Note that a block is not required to extend the best blockchain. On the contrary, it can happen that this addition may change the best blockchain.
@@ -159,8 +160,6 @@ However, the adversary remains computationally bounded. Hence, it cannot, in a p
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Non-Interactive~Proofs-of-Proof-of-Works}
\label{sec:kiayias}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -183,6 +182,21 @@ The scheme requires every block header to store pointers to the last superblock
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.
\begin{figure}
\centering
\begin{subfigure}[b]{\linewidth}
\includegraphics[width=1\linewidth]{figs/compression.drawio.pdf}
\caption{Blockchain before compression, separated into a stable and unstable part.}
\end{subfigure}
\par\bigskip
\begin{subfigure}[b]{\linewidth}
\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.}
\end{subfigure}
\caption{\label{fig:compression} Kiayias~\textit{et al.}'s compression scheme~\cite{kiayias2021mining}pas.}
\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.
@@ -217,14 +231,12 @@ Any scheme for operating and compressing blockchains requires to design (i) a \e
\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.
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.
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}
@@ -251,9 +263,7 @@ Let $\Pi_1, \Pi_2, \ldots, \Pi_n$ be the different compressed blockchains that a
% The compressed chain $\Pi = \pi\chi$ constitutes an instance of the NIPoPoW proof.
% \subsection{Comparison algorithm}
%\subsection{Properties}
%\section{Variable difficulty setting}
@@ -276,7 +286,7 @@ A robust blockchain protocol must ensure the following properties~\cite{cryptoep
\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.
The problem of blockchain becoming of considerable size was initially predicted by Satoshi Nakamoto 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.
@@ -317,7 +327,6 @@ The main idea of their solution is \emph{(i)} to attach increasing weights $W_\
\item Link of $m$ related to $|epoch|$?
\end{itemize}
The protocol described in Kiayias~\textit{et al.}~\cite{kiayias2021mining} works only in a constant difficulty setting.
That is, participants cannot join or leave the network, the number of participants is set from the start.
This entails a number of limitation rendering the protocol inoperative in the variable difficulty setting.
@@ -338,10 +347,8 @@ Finally, the previous solution's compression algorithm does not account for a va
Subsequent compressions with different value for $m$ can lose blocks that would have been included otherwise.
Since one might need blocks that have been previously discarded, the Online property of Mining in Logarithmic Space is no longer valid in the variable difficulty setting.
\subsection{Evaluating the rarity of a block}
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.
@@ -377,7 +384,6 @@ Note that any valid block has a level at least \(k=0\), since we have \( \mathfr
Our state compression protocol follows the same guidelines as Kiayias~\textit{et al.}~\cite{kiayias2021mining}.
\begin{itemize}
\item Compress chains using D/T ratio rarity instead of superblocks.
\item Rarity introduced by sorting ratios into exponentially rarer buckets.
@@ -417,7 +423,6 @@ We modify the algorithm given by Kiayias~\textit{et al.}~\cite{kiayias2021mining
Given a chain $\mathcal{C}$ we want to compress, we set aside the most recent and unstable $k$ blocks in $\chi$.
The remaining $\mathcal{C}[:-k]$ constitutes our stable part of the chain.
\begin{algorithm}
\caption{Chain compression algorithm.}\label{alg:compression}
\begin{algorithmic}
@@ -445,7 +450,6 @@ The remaining $\mathcal{C}[:-k]$ constitutes our stable part of the chain.
\end{algorithmic}
\end{algorithm}
\begin{algorithm}
\caption{State comparison algorithm.}\label{alg:comparison}
\begin{algorithmic}
@@ -475,10 +479,7 @@ The remaining $\mathcal{C}[:-k]$ constitutes our stable part of the chain.
\end{algorithmic}
\end{algorithm}
\paragraph{Synchronization}
We consider a node booting for the first time, holding only the genesis block.
This node is parameterized by the security parameter $m$.
We call this node a verifier.
@@ -490,10 +491,6 @@ We use the idea of a weather balloon to do so~\cite{zindros2020decentralized}.
Once the verifier has determined a value for $k$, it will connect to multiple full nodes, which we call 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, assume only one honest and one adversary.
\begin{itemize}
\item Verifier bootstraps with only the genesis block $G$.
@@ -541,7 +538,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}$
% 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
\item $\gamma$: 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
\end{itemize}