Merge pull request #28 from AAU-Dat/Related-work

Related work

Author: ironmand123

report/src/bib/main.bib

@@ -223,4 +223,4 @@ @inproceedings{10.1007/978-3-030-03332-3_15
     numpages = {33},
     keywords = {Post-quantum cryptography, Class-group action, Isogeny-based cryptography, Non-interactive key exchange, Key confirmation},
     location = {Brisbane, QLD, Australia}
-}
+}

report/src/sections/06-results.tex

@@ -12,8 +12,8 @@ \subsection{Proving and Verifying Times}\label{subsec:results:provingverifying}
     \label{fig:resulttimes}%
 \end{figure*}
 
-As mentioned in \autoref{sec:CAAUrdleproof-experiment}, CAAUrdleproofs was run with a shuffle size $\ell$ of $\{8,9,\dots,256\}$.
-Curdleproofs was only run with a shuffle size $\ell$ of $\{8,16,32,64,128,256\}$, as it is only able to run in powers of 2.
+As mentioned in \autoref{sec:CAAUrdleproof-experiment}, CAAUrdleproofs was run with a shuffle size $\ell=\{8,9,\dots,256\}$.
+Curdleproofs was only run with a shuffle size $\ell = 2^N$ of $N = \{3,4,5,6,7,8\}$, as it is only able to run in powers of 2.
 This is why the results for Curdleproofs show the shuffle size,~$\ell$, instantly going up to the next power of 2, because it theoretically would have to pad the input set until it reached the next power of 2.
 
 From the results, we can see that CAAUrdleproofs and Curdleproofs have similar proving and verifying times when~$\ell$ is a power of 2.
@@ -33,17 +33,25 @@ \subsection{Shuffle security}\label{subsec:Shuffle-security}
 
 \begin{figure*}[!htb]
     \centering
-    \subfloat[\centering]{{\includegraphics[width=0.45\textwidth]{figures/results/4096-256-p2} }}%
-    \qquad
-    \subfloat[\centering]{{\includegraphics[width=0.45\textwidth]{figures/results/5462-256-p2} }}%
-    \subfloat[\centering]{{\includegraphics[width=0.45\textwidth]{figures/results/8192-256-p2} }}%
+    \subfloat[\centering]{{\includegraphics[width=0.32\textwidth]{figures/results/4096-256-p2} }}%
+    \subfloat[\centering]{{\includegraphics[width=0.32\textwidth]{figures/results/5462-256-p2} }}%
+    \subfloat[\centering]{{\includegraphics[width=0.32\textwidth]{figures/results/8192-256-p2} }}%
     \caption{The results of the shuffle security experiment showing the mean amount of honest shuffles necessary with one standard deviation}%
     \label{fig:shufflesecurity}%
 \end{figure*}
 
+\begin{figure*}[!htb]
+    \centering
+    \subfloat[\centering]{{\includegraphics[width=0.32\textwidth]{figures/results/violin-4096} }}%
+    \subfloat[\centering]{{\includegraphics[width=0.32\textwidth]{figures/results/violin-5462} }}%
+    \subfloat[\centering]{{\includegraphics[width=0.32\textwidth]{figures/results/violin-8192} }}%
+    \caption{The results of the shuffle security experiment showing the spread of nessecary shuffle need for the shuffle to be secure}%
+    \label{fig:shufflesecurityviolin}%
+\end{figure*}
+
 The results of the shuffle security experiment are shown in \autoref{fig:shufflesecurity}.
 
-\autoref{fig:shufflesecurity} shows the mean of the 1000 runs of each shuffle size $\ell$ as well as one standard deviation higher and lower.
+\autoref{fig:shufflesecurity} shows the mean of the 1000 runs of each shuffle size $\ell$ and the standard deviation.
 
 We can see that the bigger the shuffle size $\ell$ is, the less honest shuffles are necessary to make the shuffle secure.
 In Ethereum, each shuffling phase is limited to 8192 shuffles, meaning that the maximum number of honest shuffles that can be used is 8192.
@@ -64,19 +72,14 @@ \subsection{Shuffle security}\label{subsec:Shuffle-security}
 Another thing that differs between the experiments is that they all have a sudden dip in higher $\ell$ values in the experiment.
 Here we see a trend that the lower the~$\alpha$ is, the earlier the dip happens.
 
-\begin{figure*}[!htb]
-    \centering
-    \subfloat[\centering]{{\includegraphics[width=0.45\textwidth]{figures/results/violin-4096} }}%
-    \qquad
-    \subfloat[\centering]{{\includegraphics[width=0.45\textwidth]{figures/results/violin-5462} }}%
-    \subfloat[\centering]{{\includegraphics[width=0.45\textwidth]{figures/results/violin-8192} }}%
-    \caption{The results of the shuffle security experiment showing the spread of nessecary shuffle need for the shuffle to be secure}%
-    \label{fig:shufflesecurityviolin}%
-\end{figure*}
+
 
 The results in \autoref{fig:shufflesecurityviolin} show that for all three $\alpha$ values, the spread of the necessary honest shuffles tightens the larger the shuffle size $\ell$ gets.
 Like the results in \autoref{fig:shufflesecurity}, \autoref{fig:shufflesecurityviolin} also shows that the bigger a shuffle size $\ell$, the less honest shuffles on average are necessary to make the shuffle secure.
 
+We can also see that the widest point of the violin plot is below the mean.
+This means that the outliers are a lot more significant above the mean than below it.
+
 It is worth noting that there is a spike in the distribution of the necessary honest shuffles at $\ell=32$ for $\alpha=4096$.
 This spike is not present for the other two $\alpha$ values, and is due to the probabilistic nature of the shuffling method.
 

report/src/sections/07-discussion.tex

@@ -38,10 +38,27 @@ \subsection{CAAUrdleproofs in comparison to Curdleproofs}\label{subsec:CAAUrdlep
 
 \subsection{Shuffle Security}\label{subsec:Discution-Shuffle-security}
 When looking at the results of the shuffle security experiment in \autoref{fig:shufflesecurity} and \autoref{fig:shufflesecurityviolin}, we can see that when taking into account the standard deviation, the shuffle can still be secure with an~$\ell$ as low as 32 within the 8192 shuffles available.
-Even when taking into account the worst case scenario from our experiment, the shuffle will still be secure with an~$\ell$ as low as 42 within the 8192 shuffles available.
-
-We would however not recommend using an~$\ell$ lower than 80, as the worst case scenario uses a little under half the available shuffles, and you would only need one third to get within the standard deviation.
-This would still lead to the size of the block overhead and the speed of the protocol being significantly reduced.
+Even when taking into account the worst case scenario from our experiment, the shuffle will still be secure with an~$\ell$ as low as 42 within the 8192 shuffles available with an $\alpha$ of 8192.
 
+We would however not recommend using an~$\ell$ lower than 80, as here the worst case scenario needs a little under half the available shuffles to be honest in order to be secure.
+As seen in~\autoref{fig:shufflesecurity} you would also only need a third of the 8192 shuffles to be honest to get within the one standard deviation.
+This would still lead to a reduction of the proving time of 62.69ms, which is 74.25\% of the current Curdleproofs time and a reduction in the verifying time of 0.89ms, which is 96.11\% of the current Curdleproofs time.
+It would also reduce the size of the block overhead from 16.656KB to 12.048KB.
+Only 72.33\% of the currently calculated size for Curdleproofs.
+This would result in saving $\sim 12.11GB$ of space on the blockchain each year.
+Some other things to keep in mind when deciding on how many honest shuffles should be necessary to make the shuffle secure is that there are other factors that can affect the security of the blockchain.
+One of such factors is some of the know attacks that takes advantage of controlling a large number of validators.
+Attacks like the $>-50\%$ stake attack and the $33\%$ finality attack~\cite{EthereumAttackDefense2024} takes advantage of controlling a large number of validators in order to negatively effect the blockchain system.
+Because of attacks like these, which rely on controlling a large number of validators, we would recommend that when evaluating how many honest shuffles should be necessary to make the shuffle secure, one should also take into account how many honest validators are necessary to make the blockchain secure.
 
+Another thing to keep in mind is that within the Ethereum system not every validator is owned by a different person.
+Some nodes contain multiple validators, and this means that during the shuffling phase, when selecting the 16384 possible proposers, there is a chance that a single node controls multiple of the chosen validators.
+This is also possible during the selecting of the shufflers.
 
+From the results we see that the mean starts higher and ends lower for the experiments with a higher $\alpha$.
+One of the reasons for this could be the relationship between the number of adversarial tracked cups and the threshold necessary before the shuffle is secure.
+Since the threshold is $2/(n-\alpha)$, the higher $\alpha$ is, the higher the threshold for the amount of water allowed in any cup.
+Therefore, the higher $\alpha$ is, the harder it is to get the water divided into the honest cups.
+The reason being, that the distribution only happens in honest cups. 
+More adversarial cups means less honest cups to distribute the water into.
+Hence, there potentially is a higher amount of water in the chosen cups after a shuffle when $\alpha$ is higher.