Update on Overleaf.
This commit is contained in:
loic.miller
node
173
ccs-body.tex
Normal file
173
ccs-body.tex
Normal file
@@ -0,0 +1,173 @@
|
||||
\section{Introduction}\label{sec:introduction}
|
||||
|
||||
Blockchain~\cite{nakamoto2008bitcoin} technology has come a long way in recent years, but one major issue that still persists is the lack of scalability.
|
||||
Today's blockchain systems struggle to handle the large amount of data that needs to be stored and transmitted between nodes when they are trying to synchronize with each other or bootstrap from the network.
|
||||
This lack of scalability limits the adoption of blockchain technology and hinders its potential to revolutionize a variety of industries.
|
||||
|
||||
Blockchain data comes in two types: \textit{application data} and \textit{consensus data}.
|
||||
Application data includes transactions, account balances, smart contract state evolution, and everything else included in the block data itself.
|
||||
Consensus data includes consensus-critical information such as proof-of-work or proof-of-stake and nonces required to discover the longest chain.
|
||||
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.
|
||||
|
||||
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 prove that the properties needed to maintain security of the protocol still hold in a dynamic context.
|
||||
Our contributions are as follows:
|
||||
\begin{itemize}
|
||||
\item Study of the mining in logarithmic space protocol in the dynamic context.
|
||||
\item Modification of the protocol to account for said dynamicity.
|
||||
\item Proof of properties in the dynamic context.
|
||||
\end{itemize}
|
||||
|
||||
Section~\ref{sec:related} presents the related work.
|
||||
Section~\ref{sec:background} talks about consensus and application data.
|
||||
|
||||
|
||||
|
||||
\section{Related Work}\label{sec:related}
|
||||
|
||||
\begin{table*}
|
||||
\caption{Comparison to other works.}
|
||||
\adjustbox{max width=\textwidth}{%
|
||||
\centering
|
||||
\begin{tabular}{cllllcccccr}
|
||||
\toprule
|
||||
& \textbf{BTC Full} & \textbf{BTC SPV} & \textbf{Ethereum} & \textbf{Superblock NIPoPows} & \textbf{FlyClient} & \textbf{Mining in Log. Space} & This work \\
|
||||
\midrule
|
||||
\textbf{Prover storage} & n(c+$\delta$) & nc + log($\delta$) & nc + k$\delta$ + a & nc + k$\delta$ + a & nc + k$\delta$ + a & poly log(n)c + k$\delta$ + a & ? \\
|
||||
\textbf{Communication} & n(c+$\delta$) & nc + log($\delta$) & nc + k$\delta$ + a & poly log(n)c + k$\delta$ + a & poly log(n)c + k$\delta$ + a & poly log(n)c + k$\delta$ + a & ? \\
|
||||
\textbf{Can verifier mine?} & Yes & No & Yes & No & No & Yes & Yes? \\
|
||||
\textbf{Works in variable difficulty?} & Yes & Yes & Yes & No & Yes & No & Yes? \\
|
||||
\bottomrule
|
||||
\end{tabular}}
|
||||
\label{tab:comp}
|
||||
\end{table*}
|
||||
|
||||
|
||||
|
||||
\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.
|
||||
|
||||
\subsection{Bootstrapping}
|
||||
|
||||
\subsection{Consensus data}
|
||||
|
||||
|
||||
|
||||
\section{MLS does not work variable setting}
|
||||
|
||||
\begin{itemize}
|
||||
\item $k$ is static, it should vary with mining power.
|
||||
\item Superblocks only compare relative difficulties, not absolute.
|
||||
\item Comparison algorithm does not take into account absolute difficulty.
|
||||
\item Compression algorithm can lose blocks if left as is.
|
||||
\item Online property broken by potential lost blocks.
|
||||
\end{itemize}
|
||||
|
||||
\section{State compression}\label{sec:compression}
|
||||
|
||||
\begin{itemize}
|
||||
\item $k$ not correlated to $m$ anymore.
|
||||
\item Link of $m$ related to $|epoch|$?
|
||||
\item Compress chains using D/T ratio rarity instead of superblocks.
|
||||
\item Rarity introduced by sorting ratios into exponentially rarer buckets.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
\section{Synchronization}\label{sec:synchronization}
|
||||
|
||||
\begin{itemize}
|
||||
\item Verifier bootstraps with only the genesis block $G$.
|
||||
\item Weather balloon to determine value for $k$.
|
||||
\item Apply MLS algorithm to compare proofs, heaviest chain from last common ancestor wins.
|
||||
\end{itemize}
|
||||
|
||||
\begin{theorem}[Security]
|
||||
Whenever the verifier receives a proof $\Pi$ constructed by an honest party and a proof $\Pi'$ constructed by the adversary, it will decide in favour of the honest proof, unless the adversary is playing honestly and $\Pi'$ was generated according to the protocol.
|
||||
\end{theorem}
|
||||
|
||||
\begin{proof}[Sketch]
|
||||
The theorem holds due to the Common Prefix Property.
|
||||
\end{proof}
|
||||
|
||||
\begin{theorem}[Online]
|
||||
Consider $\Pi = Compress_{m,k}(C)$ generated about an underlying honest chain $C$, and a block $b$ mined on top of $C$.
|
||||
Then $Compress_{m,k}(Cb) = Compress_{m,k}(\Pi b)$.
|
||||
\end{theorem}
|
||||
|
||||
\subsection{Weather balloon}
|
||||
|
||||
Use interactive version for now.
|
||||
|
||||
\begin{itemize}
|
||||
\item Use weather balloon to count the number of mined blocks.
|
||||
\item Number of blocks gives us the estimated population/mining power.
|
||||
\item Estimation gives us a value for $k$.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
\section{Analysis}\label{sec:analysis}
|
||||
|
||||
|
||||
|
||||
\section{Conclusion}\label{sec:conclusion}
|
||||
|
||||
|
||||
|
||||
|
||||
\appendix
|
||||
|
||||
\section{Appendix}
|
||||
|
||||
Paper formatted using https://github.com/acmccs/format.
|
||||
|
||||
|
||||
|
||||
\begin{acks}
|
||||
% TODO: For the submission, don't include acknowledgments since they would most likely deanonymize you.
|
||||
\end{acks}
|
||||
Reference in New Issue
Block a user