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 14:42:59 +00:00
committed by node
parent d4dcccd834
commit 1aa24ffa63
1 changed files with 60 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files

116
ccs-body.tex
View File

@@ -31,6 +31,65 @@ Our contributions are as follows:
\item Proof of properties in the dynamic context. \item Proof of properties in the dynamic context.
\end{itemize} \end{itemize}
\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?
\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.
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.
There are two primary schools of thought regarding what should be stored in each block in a blockchain system.
The first school advocates for storing only transactions, which represent the changes made to the application state.
The application state at the end of the blockchain can then be computed by starting at the genesis application state and traversing the blockchain, applying the state evolution described by each block in order to arrive at the final application state.
The second school argues for storing both transactions and the state after these transactions have been applied (called a snapshot), in each block.
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.
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.
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.
\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.
\subsection{Consensus data}
Consensus...
\section{Related Work}\label{sec:related} \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 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.
@@ -45,10 +104,6 @@ The authors in~\cite{jain2022extending} propose a scheme to construct a succinct
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. 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. %Section~\ref{sec:background} talks about consensus and application data.
\begin{table*} \begin{table*}
\caption{Comparison to other works.} \caption{Comparison to other works.}
\adjustbox{max width=\textwidth}{% \adjustbox{max width=\textwidth}{%
@@ -142,57 +197,6 @@ 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. \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} %\end{itemize}
\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?
\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.
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.
There are two primary schools of thought regarding what should be stored in each block in a blockchain system.
The first school advocates for storing only transactions, which represent the changes made to the application state.
The application state at the end of the blockchain can then be computed by starting at the genesis application state and traversing the blockchain, applying the state evolution described by each block in order to arrive at the final application state.
The second school argues for storing both transactions and the state after these transactions have been applied (called a snapshot), in each block.
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.
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.
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.
\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.
\subsection{Consensus data}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Non-Interactive~Proofs-of-Proof-of-Works} \section{Non-Interactive~Proofs-of-Proof-of-Works}
@@ -528,7 +532,7 @@ For the common prefix to hold, we need $k \geq \frac{\theta \gamma m}{4 \tau}$.
% Page 2 Garay variable difficulty % 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 $\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}$
% ñ definition page 172 Zindros thesis % ñ definition page 172 Zindros thesis
% teste % testeok
\end{itemize} \end{itemize}
\section{Analysis}\label{sec:analysis} \section{Analysis}\label{sec:analysis}