Merge pull request #27 from AAU-Dat/resdisprot

Resdisprot

Author: ironmand123

report/src/sections/04-Approach.tex

@@ -297,7 +297,7 @@ \subsubsection{CAAUdleproofs}
 Curdleproofs' implementation is simpler than CAAUrdleproofs' in this case.
 As Curdleproofs works on powers of two, it is always the right half of the vectors in each round that are multiplied by the challenge.
 
-The multiplication of challenges are not as easily trackable in the CAAUrdleproofs protocol.
+The multiplication of challenges on each element is not as easily trackable in the CAAUrdleproofs protocol.
 Here, it is necessary to simulate a run though the recursive protocol.
 Though, this should not have a big impact on performance, as it is run over vectors of small integers, and never actually has to do any multiplications.
 It is simply used as a measuring tool.
@@ -370,6 +370,11 @@ \subsubsection{CAAUdleproofs}
 So, the modifications and optimization used on the~\gls{sameperm} argument are also used on the~\gls{samemsm} argument.
 This includes the split into set $T$ and $S$ before recursion, and the construction of the bit matrix,~$b_{i,j}$, to keep track of multiplications on individual elements.
 
+It is also worth noting that the concatenation of $T$ and $S$ in the recursive phase, lines 26--29 in~\autoref{lst:ipa-prover}, is handled effectively in the code.
+Instead of concatenating, the computation uses pointers to the original vector, so it never practically concatenates.
+
+The code is also using the fact that the used scheme function will always end up with vectors being a power of two after the first round.
+So, after the first round of recursion, we use the same code as Curdleproofs to run the rest of the protocol.
 
 \subsubsection{Shuffle Security}
 As mentioned in~\autoref{subsec:approach-shuffle-security}, the theoretically proven bound, on the necessary number of shuffles to ensure security is too high.
@@ -399,17 +404,19 @@ \subsubsection{Size reduction}
 We first set our focus on Curdleproofs, as this is the protocol we have modified directly.
 As mentioned in~\autoref{sec:background-zkps}, the size of Curdleproofs is $18+10 \log(\ell+4)\mathbb{G}$, $7\mathbb{F}$.
 The dependence on the $\log$ stems from the number of recursive rounds that take place in the~\gls{sameperm} and~\gls{samemsm} proofs.
+The addition of four elements in the $\log$ stems from the protocol needing those as blinders.
+Hence, at a proof of size 128, $\ell$ is 124.
 In the proof of theorem 1, we show CAAUrdleproofs to be $\mathcal{O}(\log n)$.
 This means that the size of CAAUrdleproofs must be $18+10 \lceil\log(\ell+4)\rceil\mathbb{G}$, $7\mathbb{F}$.
 
 CAAUrdleproofs therefore has the same proof size as Curdleproofs.
 
 The CAAUrdleproofs modification can still reduce the overall block size overhead, though.
-Using Whisk with CAAUrdleproofs has a block size of $17.04$ KB, when the shuffle size is 128\cite{Whisk2024}.
+Using Whisk with CAAUrdleproofs has a block size of $16.656$ KB, when the shuffle size is 128\cite{Whisk2024}.
 Note that this is the same size as Curdleproofs, as the shuffle size is a power of 2.
 The calculation of the block size comes from the following, where $\mathbb{G}=48$ bytes and $\mathbb{F}=32$ bytes\footnote{\text{As noted in the code on the Curdleproofs GitHub repository: }\\ \href{https://github.com/asn-d6/curdleproofs/blob/main/src/whisk.rs}{https://github.com/asn-d6/curdleproofs/blob/main/src/whisk.rs}. Accessed: 26/05/2025}:
 \begin{itemize}
-    \item List of shuffled trackers ($\ell\cdot96\Rightarrow\text{eg. }128\cdot96=12,288$ bytes).
+    \item List of shuffled trackers ($\ell\cdot96\Rightarrow\text{eg. }124\cdot96=11,904$ bytes).
     \item Shuffle proof ($18+10 \lceil\log(\ell+4)\rceil\mathbb{G}$, $7\mathbb{F}\Rightarrow\text{eg. }(18+10\lceil\log(124+4)\rceil)\cdot48+7\cdot32=4,448$ bytes).
     \item A fresh tracker (two BLS G1 points $\Rightarrow48\cdot2=96$ bytes).
     \item A new commitment $com(k)$ to the proposer's tracker (one BLS G1 point $\Rightarrow48$ bytes).

report/src/sections/06-results.tex

@@ -1,6 +1,8 @@
 \section{Results}\label{sec:results}
 \subsection{Proving and Verifying Times}\label{subsec:results:provingverifying}
 
+After running the experiment where Curdleproofs and CAAUrdleproofs were compared across different shuffle sizes, we got the results shown in \autoref{fig:resulttimes}.
+
 \begin{figure*}[!htb]
     \centering
     \subfloat[\centering Proving Time]{{\includegraphics[width=0.45\textwidth]{figures/results/provingtime} }}%
@@ -10,18 +12,20 @@ \subsection{Proving and Verifying Times}\label{subsec:results:provingverifying}
     \label{fig:resulttimes}%
 \end{figure*}
 
-After running the experiment where Curdleproofs and CAAUrdleproofs were compared across different shuffle sizes, we obtained the results shown in \autoref{fig:resulttimes}.
-
-As mentioned in \autoref{sec:CAAUrdleproof-experiment}, CAAUdleproofs was run with a shuffle size $\ell$ of $\{8,9,\dots,256\}$ but Curdleproofs was only run with a shuffle size $\ell$ of $\{8,16,32,64,128,256\}$.
-This is why the results for Curdleproofs show the shuffle size, $\ell$, instantly goes 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.
+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.
+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.
-However, when $\ell$ is not a power of 2, CAAUrdleproofs is faster.
+From the results, we can see that CAAUrdleproofs and Curdleproofs have similar proving and verifying times when~$\ell$ is a power of 2.
+However, when~$\ell$ is not a power of 2, CAAUrdleproofs is faster.
+When $\ell$ is below a power of 2, we see that the performance advantage of CAAUrdleproofs contra Curdleproofs grows the lower~$\ell$ is.
 
-The results for the verifying time also shows that the verifying time jumps up the first four times it reaches a power of 2.
+The results for the verifying time also show that the verifying time jumps up quite significantly the first four times it reaches a power of 2.
+Though, this seems to not be the case, at least not as aggressively, when increasing $\ell$ from 128.
+We find, however, that the bump is smaller the higher $\ell$ is.
 
-Additional to the proving and verifying times, the time used on shuffling is also lower for any $\ell$ that is not a power of 2.
-Though, that was to be expected since CAAUrdleproofs uses the same shuffling algorithm as Curdleproofs but does not have to add additional padding values to the non power of 2 input sizes.
+Additional to the proving and verifying times, the time used on shuffling is also lower for any $\ell$ that is not a power of 2; see~\autoref{sec:shuffling-results}.
+Though, that was to be expected since CAAUrdleproofs uses the same shuffling algorithm as Curdleproofs, but does not have to add additional padding to the non-power of 2 input sizes.
 
 
 
@@ -44,21 +48,21 @@ \subsection{Shuffle security}\label{subsec:Shuffle-security}
 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.
 Therefore, the results of the experiment also find $T_H=T-\beta$.
-This is how many of the $T$ shuffles, available during the shuffling phase, are needed to be honest, $T_H$, shuffles.
+This is how many of the $T$ shuffles, available during the shuffling phase, are needed to be honest~$T_H$ shuffles.
 The rest could then be the number of dishonest shuffles,~$\beta$.
-We also see that the bigger the shuffle size the narrower the standard deviation gets.
+We also see that the bigger the shuffle size, the narrower the standard deviation gets.
 
-From the results of the experiment with $\alpha=8192$ we can see that number of honest shuffles necessary to make the shuffle secure sharply goes down until a size of $\ell=64$, and then it starts to flatten out.
+From the results of the experiment, with~$\alpha=8192$ we can see that the number of honest shuffles necessary to make the shuffle secure sharply goes down until the size of $\ell=64$, and then it starts to flatten out.
 we can see that with a size of $\ell=75$ we need about 1/3 of the shuffles to be honest to make the shuffle secure.
-Likewise, we can see the at $\ell=108$ we need about 1/4 of the shuffles to be honest to make the shuffle secure.
-
-In general all three of the experiments, despite the difference in $\alpha$, show the same trend.
-They all level out but the higher the $\alpha$ is, the lower the leveling happens but the later it happens as well.
-There are two things however that are different between the experiments.
-At an $\alpha$ of 4096 we can see that at the start, with $\ell=32$, the mean number of honest shuffles necessary to make the shuffle secure is $\sim500$ lower than the 2 others.
-As $\ell$ increases, the mean number of honest shuffles necessary to make the shuffle secure becomes similar to the other $\alpha$ values.
-Another thing that differs between the experiments is that they all have sudden dip later on in the experiment.
-Here we can see a trend that the lower the~$\alpha$ is, the earlier the dip happens.
+Likewise, we see that at~$\ell=108$ we need about 1/4 of the shuffles to be honest to make the shuffle secure.
+
+In general, all three of the experiments, despite the difference in $\alpha$, show the same trend.
+They all level out, but the higher~$\alpha$ is, the lower the leveling happens, but the later it happens as well.
+There are two things, however, that are different between the experiments.
+At an~$\alpha$ of 4096 we see that at the start, with $\ell=32$, the mean number of honest shuffles necessary to make the shuffle secure is $\sim 500$ lower than the 2 others.
+As~$\ell$ increases, the mean number of honest shuffles necessary to make the shuffle secure becomes similar to the other $\alpha$ values.
+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

report/src/sections/07-discussion.tex

@@ -6,9 +6,35 @@ \section{Discussion}\label{sec:discussion}
 
 
 \subsection{CAAUrdleproofs in comparison to Curdleproofs}\label{subsec:CAAUrdleproofs-vs-Curdleproofs}
-
-
-
+As mentioned in~\autoref{subsec:results:provingverifying}, the proving and verifying times between the two protocols are close to identical when $\ell$ is a power of two.
+We expect that this is because the added computation is negligible compared to other computations that are present in the original Curdleproofs protocol.
+
+On the prover, there is the addition of the scheme function from Springproofs.
+Though, as seen in~\autoref{lst:schemefunc}, the scheme function only makes integer calculations based on $n$, and hence should have a negligible impact compared to the cryptographic group computations.
+In addition to that, mentioned in~\autoref{subsec:approach-implementation}, the vector is never practically split in two but instead uses pointers.
+Therefore, we avoid having to add new variables to memory in every round.
+
+Also, we mentioned in~\autoref{subsec:approach-implementation} that, every round after the first, runs the same code as Curdleproofs.
+Thus, only the first round should be able to introduce some computational overhead.
+But, as mentioned before, the overhead should be negligible.
+
+The same kind of explanation can be used to describe the same scenario at powers of two on the verifier side.
+Looking at~\autoref{lst:ipa-verifier-optimized}(b), we see that the only difference in computation between CAAUrdleproofs and Curdleproofs stems from the calculation of $\mathbf{s}$.
+Comparing line 29 and lines 33--47, it becomes clear that both ways work in $\mathcal{O}(n\log n)$, as they do $m$ computations for each of the $n$ elements.
+CAAUrdleproofs does, however, need some more integer variables for splitting as well as an array for keeping track of the vector elements' active positions during recursion.
+Nevertheless,~\autoref{fig:resulttimes}(b) shows that this does not have a big, if any, impact on the running time.
+
+However, as mentioned in~\autoref{subsec:results:provingverifying}, when~$\ell$ is just above a power of two, we see some more aggressively increasing verifying times.
+We expect this to be a result of~$m$ being set to~$\lceil\log n\rceil$ in line 8 of~\autoref{lst:ipa-verifier-optimized}.
+E.g., when~$\ell$ is~$65$, it will have to handle computations from an additional recursive round, in comparison to when~$\ell$ is~$64$.
+Additionally, this also explains why the increase in running time flattens when~$\ell$ is increases.
+
+Though the pattern shows that this bump has a decreasing impact on the running time, the higher $\ell$ is, as mentioned in~\autoref{subsec:results:provingverifying}.
+In theory, the addition of an extra proof element should introduce a constant amount of work for the verifier.
+
+Therefore, we believe this to be an artifact of memory optimizations done either by hardware or Rust.
+This could, for instance, include pre-fetching, in which the memory system can optimize access if it suspects some values in memory are going to be used some time later on\footnote{\href{https://doc.rust-lang.org/core/arch/aarch64/fn._prefetch.html}{https://doc.rust-lang.org/core/arch/aarc.h64/fn.\_prefetch.html} — Accessed: 29/05/2025}.
+As $\ell$ increases, the memory system will have more data to predict and optimize memory access.
 
 \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.

report/src/sections/aa-appendix.tex

@@ -5,4 +5,5 @@
 % Insert appendix sections below
 \input{sections/appendix/01-appendix}
 \input{sections/appendix/02-thm1proof}
-\input{sections/appendix/03-bpplus}
+\input{sections/appendix/03-bpplus}
+\input{sections/appendix/04-shuffling-times}

report/src/sections/appendix/04-shuffling-times.tex

@@ -0,0 +1,6 @@
+\section{Shuffling results}\label{sec:shuffling-results}
+\begin{figure}[!htb]
+    \includegraphics[width=0.48\textwidth]{figures/results/shufflingtime}
+    \caption{The shuffling times at each benchmark}%
+    \label{fig:shufflespeed}%
+\end{figure}