From e07eea27a7084b4dff1a4ae81e95dc4fbf4f03d4 Mon Sep 17 00:00:00 2001 From: Maltesius Date: Sun, 8 Jun 2025 12:05:18 +0200 Subject: [PATCH] Readthrough changes --- report/src/sections/00-abstract.tex | 8 +-- report/src/sections/01-introduction.tex | 12 ++--- report/src/sections/02-background.tex | 23 +++++---- report/src/sections/03-related-work.tex | 22 ++++---- report/src/sections/04-Approach.tex | 50 +++++++++---------- .../src/sections/05-experimental-protocol.tex | 15 +++--- report/src/sections/06-results.tex | 12 ++--- report/src/sections/07-discussion.tex | 8 +-- report/src/sections/08-conclusion.tex | 10 ++-- .../sections/appendix/04-shuffling-times.tex | 3 ++ report/src/setup/acronyms.tex | 2 +- 11 files changed, 82 insertions(+), 83 deletions(-) diff --git a/report/src/sections/00-abstract.tex b/report/src/sections/00-abstract.tex index 00f5fe9..1e8e2aa 100644 --- a/report/src/sections/00-abstract.tex +++ b/report/src/sections/00-abstract.tex @@ -1,11 +1,11 @@ \begin{abstract} - Ethereum is one of the leading proof-of-stake blockchains. + Ethereum is one of the leading Proof-of-Stake blockchains. However, it is still vulnerable to attacks. One such attack is the de-anonymization attack by Heimbach et al.~where an adversary could get validator IP addresses and then perform a denial-of-service attack on them. To try and combat this attack, Ethereum has proposed the use of the Whisk protocol. - Whisk is a Single secret leader election protocol that uses a zero-knowledge proof called Curdleproofs that uses inner product arguments to prove the validity of a shuffle of validators. - This paper improves upon Curdleproofs' inner product arguments by introducing CAAUrdleproofs, which is a modified version of Curdleproofs with ideas from Springproofs as to overcome the limitations of Curdleproofs regarding the shuffle size. + Whisk is a Single Secret Leader Election protocol that uses a zero-knowledge proof called Curdleproofs that uses Inner Product Arguments to prove the validity of a shuffle of validators. + This paper improves upon Curdleproofs' Inner Product Arguments by introducing CAAUrdleproofs, which is a modified version of Curdleproofs with ideas from Springproofs as to overcome the limitations of Curdleproofs regarding the shuffle size. We show that CAAUrdleproofs has similar proving and verifying times to Curdleproofs when the shuffle size is a power of two. We also show that CAAUrdleproofs has a performance advantage for any shuffle size that is not a power of two, and that this advantage grows the lower the shuffle size is below a power of two. After performing experiments, we also suggest a new shuffle size which is smaller than the current one used in Curdleproofs that would result in a smaller block overhead than the one created by the current Curdleproofs protocol. @@ -14,5 +14,5 @@ \end{abstract} \begin{IEEEkeywords} - Ethereum, Proof of Shuffle, Distributed Systems, Inner Product Arguments, Zero-Knowledge Proof + Ethereum, Proof of Shuffle, Distributed Systems, Inner Product Arguments, Zero-Knowledge Proof, Single Secret Leader Election \end{IEEEkeywords} diff --git a/report/src/sections/01-introduction.tex b/report/src/sections/01-introduction.tex index 48af1a7..820f092 100644 --- a/report/src/sections/01-introduction.tex +++ b/report/src/sections/01-introduction.tex @@ -3,27 +3,27 @@ \section{Introduction}\label{sec:introduction} Ethereum is a decentralized blockchain platform that enables developers to build and deploy smart contracts and decentralized applications. It is the second-largest blockchain platform by market capitalization and has a large and active developer community. -Currently working as a Proof-of-Stake protocol, block proposal opportunities are allocated to the community members willing to stake their ether cryptocurrency on entities called validators. +Currently working as a Proof-of-Stake protocol, block proposal opportunities are allocated to validators, which can be created by community members willing to stake their ether cryptocurrency. Though, previous work from Heimbach et al., confirmed also by our previous study, shows that adversaries are able to gather validator IP addresses~\cite{heimbach2024deanonymizingethereumvalidatorsp2p,ouroldpaper}. These can be used to perform a Denial-of-Service (DoS) attack on the validators, threatening the liveness of the blockchain~\cite{EthereumAttackDefense2024,ouroldpaper}. -In response to the potential threat, Ethereum has proposed a protocol, Whisk, which hides validators' identities making the DoS attack harder to perform~\cite{Whisk2024}. +In response to the potential threat, Ethereum has proposed a protocol, Whisk, which hides block proposers' identities making the DoS attack harder to perform~\cite{Whisk2024}. Whisk is a Single Secret Leader Election (SSLE) protocol~\cite{10.1145/3419614.3423258}, where validators each publish a private tracker, which is used for proposer selection instead. When proposing a block, the validator will then prove the ownership of the tracker. To ensure that adversaries are unable to trace the tracker to specific validators, each block proposer shuffles the list of validator trackers while adding randomness to the trackers. Making sure that this has been done correctly is essential to the protocol. -Hence, Whisk uses a proof protocol, called Curdleproofs, which is a Zero-Knowledge proof of shuffle~\cite{Curdleproofs}. +Hence, Whisk uses a proof protocol, called Curdleproofs, which is a Zero-Knowledge Proof of Shuffle~\cite{Curdleproofs}. Therefore, the block proposer constructs such a proof, adds it to the block, after which other validators can verify the proof. -This introduces block size overhead to the blockchain. +This introduces a block size overhead to the blockchain. Also, additional work is required for both provers and verifiers. In this paper, we dive into the structure of Curdleproofs to understand, where the protocol can be optimized. -Specifically, we work with the concept of Inner Product Arguments (IPA) and how they generally only work for vector sizes that are powers of two. +Specifically, we work with the concept of Inner Product Arguments (IPAs) and how they generally only work for vector sizes that are powers of two. Our protocol, CAAUrdleproofs, aims to improve on the rigid nature of Curdleproofs. -Following this, we also provide argumentation of in which conditions CAAUrdleproofs is still secure. +Following this, we also provide argumentation of the conditions in which CAAUrdleproofs is still secure. Working with this led to the following contributions: \begin{itemize} diff --git a/report/src/sections/02-background.tex b/report/src/sections/02-background.tex index cac5c6e..2d9dc90 100644 --- a/report/src/sections/02-background.tex +++ b/report/src/sections/02-background.tex @@ -73,7 +73,7 @@ \subsection{Zero-knowledge proofs}\label{sec:background-zkps} Definitions for knowledge-soundness, completeness, and~\gls{hvzk} can be found in Appendix~\ref{sec:appendix}. -Also, two of three proofs that make up Curdleproofs are~\glspl{ipa}. +Also, two of three proofs that make up Curdleproofs are proven using~\glspl{ipa}. These are also~\glspl{zkp}, and will be the focus of this paper. Hence, we provide a definition on~\glspl{ipa}. @@ -90,19 +90,20 @@ \subsection{Whisk}\label{subsec:related-work-whisk} The proposer~\gls{dos} attack is a type of attack that targets the block proposers, making them unable to propose blocks. An adversary can use the proposer~\gls{dos} attack to prevent a proposer from receiving rewards, gotten from proposing a block, and increase their own rewards~\cite{EthereumSSLE2024}. +The proposer~\gls{dos} is made possible by an attack on the Ethereum network that was discovered by Heimbach et al.~\cite{heimbach2024deanonymizingethereumvalidatorsp2p} in which they deanonymize validators and get their IP addresses. +In our preliminary work~\cite{ouroldpaper}, we show that the attack is still possible to perform on the Ethereum network. As a response to the proposer~\gls{dos} attack, Ethereum proposed a new protocol called Whisk~\cite{Whisk2024} as an attempt to mitigate the attack. -An attack on the Ethereum network that was discovered by Heimbach et al.~\cite{heimbach2024deanonymizingethereumvalidatorsp2p} is the deanonymization attack on validators. -In our preliminary work~\cite{ouroldpaper}, we show that the attack is still possible to perform on the Ethereum network, and using the attack, a proposer~\gls{dos} can be performed. - Whisk is a~\gls{zk}~\gls{ssle} system that uses a~\gls{zk} argument called Curdleproofs~\cite{Curdleproofs} to verify the correctness of a shuffle with size $\ell$ without revealing the input or output~\cite{10.1145/3419614.3423258}. -Whisk works by selecting a list of 16,384 validator trackers and shuffles them over 8,192 slots ($\sim$1 day). +Whisk works by selecting a list of 16,384 validator trackers and then the following 8,192 block proposers shuffle them over 8,192 slots ($\sim$1 day). Then 8,192 proposers are selected from the shuffled list to propose blocks for the next 8,192 slots while a new list is being shuffled. -This way a new list of proposers is created every day. +This way, a new list of proposers is created every day. After each shuffle, Whisk uses a~\gls{zkp} to prove that the shuffle is correct. -This is so that the proposer can prove that they are the correct proposer for the slot without revealing their identity, thereby mitigating the proposer~\gls{dos} attack because of the identity of the upcoming proposers being hidden now. +As the specific shuffle is hidden to prevent adversarial tracking, this is done to ensure that the trackers are shuffled according to protocol specifications. +Whenever a proposer is chosen, they can prove that they are the correct proposer for the slot without revealing their identity. +Thereby, Whisk mitigates the proposer~\gls{dos} attack because of the identity of the upcoming proposers being hidden now. -Curdleproofs is a~\gls{zkp} system that allows a prover to prove knowledge of a shuffle without revealing how it shuffled the elements. +Curdleproofs is a~\gls{zkp} system, used by Whisk, that allows a prover to prove knowledge of a shuffle without revealing how it shuffled the elements. It does so by using three different~\glspl{zkp}, with one of them relying on two more~\glspl{zkp}. The overview can be seen in~\autoref{fig:curdleproof-protocol}. @@ -170,8 +171,8 @@ \subsection{Whisk}\label{subsec:related-work-whisk} The second proof is a~\gls{samemsm} argument. The prover has proven the existence of the permutation. -Now, the goal of the~\gls{samemsm} argument is to prove that the output ciphertext set was constructed with the same permutation, $\sigma$, here called multiscalar $\mathbf{v}$\footnote{Denoted as $\mathbf{c}$ in the Curdleproofs paper but changed for readability}, committed to in commitment $A$. -Note, therefore, that $A$ in~\gls{sameperm} and~\gls{samemsm} is the same commitment, where $\mathbf{v}=\sigma(\mathbf{a})$ +Now, the goal of the~\gls{samemsm} argument is to prove that the output ciphertext set was constructed with the same permutation,~$\sigma$, here called multiscalar $\mathbf{v}$\footnote{Denoted as $\mathbf{c}$ in the Curdleproofs paper but changed for readability}, committed to in commitment $A$. +Note, therefore, that commitment~$A$ in~\gls{sameperm} and~\gls{samemsm} is the same commitment, where $\mathbf{v}=\sigma(\mathbf{a})$. As the multiscalar is a vector, this argument is an~\gls{ipa} by nature, contrary to the~\gls{sameperm} argument. The third proof is a Same Scalar argument. @@ -181,7 +182,7 @@ \subsection{Whisk}\label{subsec:related-work-whisk} Therefore, the goal of the Same Scalar argument is to prove the existence of the scalar,~$k$, such that the commitment of the permuted set is equal to the commitment of the pre-permuted set multiplied by $k$. -In Chapter 6 of Curdleproofs~\cite{Curdleproofs} they explain that the proof has size~$18+10 \log(\ell+4)\mathbb{G}$, $7\mathbb{F}$, where $\mathbb{G}$ is a cryptographic group point, and $\mathbb{F}$ is a field element. +In Chapter 6 of Curdleproofs~\cite{Curdleproofs} they explain that the proof has size~$(18+10 \log(\ell+4))\mathbb{G}+7\mathbb{F}$, where $\mathbb{G}$ is a cryptographic group point, and $\mathbb{F}$ is a field element. \subsection{Problem definition}\label{subsec:problem-definition} The current proposal of Curdleproofs only works when the shuffle size of Whisk is set to a power of 2. diff --git a/report/src/sections/03-related-work.tex b/report/src/sections/03-related-work.tex index 02714f4..5c1253b 100644 --- a/report/src/sections/03-related-work.tex +++ b/report/src/sections/03-related-work.tex @@ -4,7 +4,7 @@ \section{Related Work}\label{sec:related-work} \subsection{Single Secret Leader Election}\label{sec:related-work-SSLE} -A~\gls{ssle} is a protocol where a group of participants randomly elects only one leader from the group. +An~\gls{ssle} is a protocol where a group of participants randomly elects only one leader from the group. The identity of the leader is kept secret from all other participants so only the leader themselves know that they have been chosen. The elected leader can then later publicly prove that they have been elected~\cite{10.1145/3419614.3423258}. @@ -18,7 +18,7 @@ \subsection{Single Secret Leader Election}\label{sec:related-work-SSLE} Safrole is the production version of the research protocol Sassafras~\cite{sassafras}. In this, validators each produce a number of tickets, some of which are winning, depending on some threshold. A~\gls{zk-snark} is then used to prove that a ticket is winning, after which the winning tickets are published to the chain. -A randomization algorithm will then pick, from all the winning tickets, proposers for all the slots two epochs later. +A randomization algorithm will then pick proposers from all the winning tickets for all the slots two epochs later. @@ -40,17 +40,17 @@ \subsection{Shuffling algorithms}\label{subsec:related-work-shuffling-algorithm} Ethereum mentioned the reason for this to be that the shuffle by Larsen et al.\ provides a simpler protocol~\cite{Whisk2024}. \subsection{Bulletproofs}\label{subsec:related-work-bulletproofs} -A big inspiration for the Curdleproofs protocol is bulletproofs~\cite{bunz2018bulletproofs}. -Bulletproofs is a type of range proof that uses inner product arguments to prove that a committed value is within a certain range without revealing the value itself. -Bulletproofs is in itself not a zero-knowledge proof system, but with the help of Fiat Shamir~\cite{bunz2018bulletproofs} it can be used to create a zero-knowledge proof. -Bulletproofs also has had a few iterations and improvements to increase the speed and reduce the size of the proof since it was used in curdleproofs. - -One of these is Bulletproofs+~\cite{chung2022bulletproofs+} which uses a weighted inner product argument instead of the standard inner product argument to achieve a better performance. -Bulletproofs+ is also a zero-knowledge proof by itself unlike the original bulletproofs. -Trying to modify Curdleproofs with the weighted inner product argument introduces complications that would need larger modifications and is therefore not suitable. +A big inspiration for the Curdleproofs protocol is Bulletproofs~\cite{bunz2018bulletproofs}. +Bulletproofs is a type of range proof that uses~\glspl{ipa} to prove that a committed value is within a certain range without revealing the value itself. +Bulletproofs is in itself not a~\gls{zkp} system, but with the help of Fiat Shamir~\cite{bunz2018bulletproofs} it can be used to create a~\gls{zkp}. +Bulletproofs also has had a few iterations and improvements to increase the speed and reduce the size of the proof since it was used in Curdleproofs. + +One of these is Bulletproofs+~\cite{chung2022bulletproofs+} which uses a~\gls{wipa} instead of the standard~\gls{ipa} to achieve a better performance. +Bulletproofs+ is also a~\gls{zkp} by itself unlike the original Bulletproofs. +Trying to modify Curdleproofs with the~\gls{wipa} introduces complications that would need larger modifications and is therefore not suitable. This can be seen in Appendix~\ref{app:curdleproofs-weighted-inner-product-argument-modification-attempt} A third version of the Bulletproofs protocol is Bulletproofs++~\cite{eagen2024bulletproofs++} which uses a new type of argument called the norm argument to achieve a better performance. This comes from the prover only needing to commit to a single vector, rather than two. -Therefore, with the two vectors, $x$ and $y$ of a standard~\gls{ipa}, they need to assume $x=y$ for their protocol to work. +Therefore, with the two vectors, $x$ and $y$ of a standard~\gls{ipa}, they need to assume~$x=y$ for their protocol to work. Then, along with the norm being weighted, which raises the same complications as with Bulletproofs+, this makes it unsuitable for Curdleproofs. \ No newline at end of file diff --git a/report/src/sections/04-Approach.tex b/report/src/sections/04-Approach.tex index a42554c..de0996f 100644 --- a/report/src/sections/04-Approach.tex +++ b/report/src/sections/04-Approach.tex @@ -1,27 +1,25 @@ \section{approach}\label{sec:approach} - As explained in~\autoref{sec:background}, Curdleproofs makes use of three different proofs. -This work focuses on improving the underlying~\gls{ipa}, especially the running time and proof size of the protocol are of interest. -The following is our approach to, how we modified the~\gls{ipa}. +This work focuses on improving the underlying~\glspl{ipa}, especially the running time and proof size of the protocol are of interest. +The following is our approach to how we modified the~\glspl{ipa}, with focus on the~\gls{dlipa}. \subsection{Springproofs}\label{sec:approach-springproofs} The Springproofs protocol~\cite{zhang2024springproofs} can be used very effectively in solving the problem stated in~\autoref{subsec:problem-definition}. The theory of Springproofs provides support for~\glspl{ipa} to use vectors of arbitrary length. -Using the findings of Springproofs means Curdleproofs could be used on shuffle sizes other than powers of two. +Using the findings of Springproofs means Curdleproofs could be used with shuffle sizes other than powers of two. As such, they could lower the shuffle size from the current 128 to a size significantly lower, given it is still secure. -Seeing the proof size of Curdleproofs being dependent on $\ell$ means that this modification would greatly help in lowering it. One of the most notable findings in Springproofs is the usage of their so-called scheme function. This function is used to ensure that the~\gls{ipa} eventually will fold down to a vector of size 1. In a general~\gls{ipa}, Curdleproofs included, if the size of the vectors were not a power of two, the argument would not recursive down to size 1, as they work by halving the vectors every recursive round. -The core concept of the Springproofs scheme function is to split the vectors into sets, $T,S$ before each recursive round of the protocol. -Then, the fold for that round is only done on one of the two sets, $T$, before the other set, $S$, is appended again at the end of the recursive round. +The core concept of the Springproofs scheme function is to split the vectors into sets, $T$ and $S$ before each recursive round of the protocol. +Then, the fold for that round is only done on one of the two sets,~$T$, before the other set,~$S$, is appended again at the end of the recursive round. Springproofs present different scheme functions and prove some of them to be optimal. One of these optimal functions is an optimized version of their \textit{pre-compression method}, which splits the vectors as seen in~\autoref{lst:schemefunc}. -The computation is for finding the set, $T$. +The computation is for finding the set,~$T$. \begin{figure}[!htb] \begin{lstlisting}[language=Python,mathescape=true,label={lst:schemefunc},numbers=right,caption={Scheme function \textbf{\textit{f}} used in CAAUrdleproofs},captionpos=b,frame=single] @@ -41,8 +39,8 @@ \subsection{Springproofs}\label{sec:approach-springproofs} \end{figure} This can also visually be seen in~\autoref{fig:fold}(b), which is figure 1 of the Springproofs paper~\cite{zhang2024springproofs}. -In \autoref{fig:fold}(a) is a scheme function which simply pads the vector to the next power of two before running an~\gls{ipa}. -If one wanted to run current~\glspl{ipa}s on vector that are not a power of two, this would generally be the easiest way to achieve that. +In \autoref{fig:fold}(a) is a scheme function that simply pads the vector to the next power of two before running an~\gls{ipa}. +If one wanted to run current~\glspl{ipa} on vectors that are not a power of two, this would generally be the easiest way to achieve that. Though, this defeats the attempt of lowering the proof size, as it would now correspond to running an~\gls{ipa} on the size of the next power of two. \begin{figure*}[!htb] @@ -54,7 +52,7 @@ \subsection{Springproofs}\label{sec:approach-springproofs} \label{fig:fold}% \end{figure*} -It is notable to mention that using the folding as shown in~\autoref{fig:fold}(b) results in the second recursive round being a size corresponding to a power of two. +It is worth mentioning that using the folding as shown in~\autoref{fig:fold}(b) results in the second recursive round being a size corresponding to a power of two. This means that the rest of the protocol will run as a general~\gls{ipa}, without the actual need for splitting the vectors, which can also be seen in~\autoref{lst:schemefunc}. \subsection{CAAUrdleproofs}\label{subsec:approach-CAAUrdleproofs} @@ -112,7 +110,7 @@ \subsubsection*{Prover computation} To ensure zero-knowledge, two blinding vectors for each commitment are constructed on lines 3--4. These are also given the properties, $(\mathbf{r}_C\times \mathbf{d}+\mathbf{r}_D\times \mathbf{c})=0$~and~ $\mathbf{r}_C\times\mathbf{r}_D=0$, ensuring the completeness of the protocol. -After this, commitments of the blinding vectors are constructed as $B_C$ and $B_D$, on lines 5--6. +After this, commitments to the blinding vectors are constructed as $B_C$ and $B_D$, on lines 5--6. These will eventually be used for verification by the verifier. From the public input, hash values $\alpha,\beta$ are then computed on line 7. @@ -134,7 +132,7 @@ \subsubsection*{Prover computation} We do the fold as in the original Curdleproofs protocol, while also appending the elements of $S$ back onto the vectors. The figure shows a concatenation, but it is important to know that the vectors are appended together as shown in~\autoref{fig:fold}(b). -At last, on line 30,~$n$ is updated to the length of the concatenated vectors before starting a new round. +At the end of the recursive round, on line 30,~$n$ is updated to the length of the concatenated vectors before starting a new round. The result of this is a proof,~$\mathbf{\pi}$, constructed in $\lceil \log n \rceil$ rounds, but with the proof size being smaller than if the shuffle size was a power of 2. @@ -196,7 +194,7 @@ \subsubsection*{Verifier computation} Those modifications mean that the commitments~$C$ and~$D$ need to be commitments to the modified witnesses instead. The setup phase is now done, and the verifier has to also run a recursive protocol, which is shown in step 2. -First, the vectors are on line 13 divided into the two sets,~$|T|,|S|$, as in~\autoref{lst:ipa-prover}. +First, the vectors are, on line 13, divided into the two sets,~$T$ and $S$, as in~\autoref{lst:ipa-prover}. After this, the group vectors are in lines 14--16 split in according to those sets, along with updating~$n$ to be half the size of~$T$. The verifier then, on line 17, retrieves from the proof the cross-product commitment update values for the given round,~$L_{C,j},L_{D,j},R_{C,j},R_{D,j}$. @@ -224,8 +222,8 @@ \subsubsection*{Verifier computation} \subsection{Shuffle security}\label{subsec:approach-shuffle-security} -The shuffle method proposed by Larsen et al.~\cite{cryptoeprint:2022/560} that was used in Curdleproofs is based on the idea of shuffling a list of proposers over a set of slots. -A formal definition of the shuffle is given in~\autoref{fig:shuffle}~\cite{cryptoeprint:2022/560}. +The shuffle method proposed by Larsen et al.~\cite{cryptoeprint:2022/560} that is used in Curdleproofs is based on the idea of shuffling a list of proposers over a set of slots. +A formal definition of the shuffle is given in~\autoref{fig:shuffle}. \begin{figure}[!htb] \begin{framed} @@ -264,7 +262,7 @@ \subsection{Shuffle security}\label{subsec:approach-shuffle-security} The first event is a short backtracking, where an adversary can find the original ciphertexts from the shuffled ciphertexts. Since the subsets of ciphertexts are chosen randomly in each shuffle, if there are enough adversarial shufflers in a row at the end of the process, then a short backtracking is possible. -The second event that can occur is related to the fact that every shuffle distributes the possibility of a certain ciphertext to be in a certain slot. +The second event that can occur is related to the fact that every shuffle distributes the probability of a certain ciphertext to be in a certain slot. So, if a shuffle contains a lot of ciphertexts with a larger than average chance of containing a certain ciphertext, then that would imply that there is a higher chance of that ciphertext being in that slot. It is theoretically possible to find a number of shuffles, given the shuffle size, and a number of adversarial shufflers, to guarantee that the shuffle is secure. @@ -277,7 +275,7 @@ \subsection{Shuffle security}\label{subsec:approach-shuffle-security} \subsection{Implementation}\label{subsec:approach-implementation} -Implementing the above-explained CAAUrdleproofs protocol introduced some optimizations required to have the code run as fast as possible. +Implementing the above-explained CAAUrdleproofs protocol required some optimizations, made by Curdleproofs, to have the code run as fast as possible. These are explained in the following with a focus on how CAAUrdleproofs differentiates itself from Curdleproofs. Both our implementation of CAAUrdleproofs and the experiment involving the security of the shuffle are publicly available on GitHub~\footnote{\href{https://github.com/AAU-Dat/curdleproofsplus/tree/SIPA}{https://github.com/AAU-Dat/curdleproofsplus/tree/SIPA}}. The implementation of CAAUrdleproofs is a fork of and builds directly on the already existing Curdleproofs code. @@ -295,7 +293,7 @@ \subsubsection{CAAUrdleproofs} To keep track of which elements of the vectors are multiplied by each $\gamma_j$, a function called \texttt{get\_verification\_scalars\_bitstring} is used. The output of this function is a list of length $\ell$, each element with a list corresponding to the rounds in which $\gamma_j$ was multiplied to the element. 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. +As Curdleproofs only 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 on each element is not as easily trackable in the CAAUrdleproofs protocol. Here, it is necessary to simulate a run though the recursive protocol. @@ -386,9 +384,9 @@ \subsubsection{Shuffle Security} An experiment run starts with the first cup being full and the rest being empty. As mentioned, $\alpha$ cups are tracked by an adversary, the first $n-\alpha$ cups are called active cups, while the last $\alpha$ cups are tracked. -So, at each shuffle, the shuffler randomly picks $\ell$ ciphertexts and shuffles them, also randomly. -Meanwhile, an average of the water between the active indices of the $\ell$-shuffle is found. -All active indices are given this amount of water. +So, at each shuffle, the shuffler randomly picks $\ell$ ciphertexts and shuffles them. +Meanwhile, an average of the water between the active cups of the $\ell$-shuffle is found. +All active cups are given this amount of water. Now, after each shuffle, if any cup has more than $2/(n-\alpha)$ water, its position can be predicted by the adversary, hence the shuffle is insecure~\cite{cryptoeprint:2022/560}. If a position can be predicted, another round of shuffling is performed. @@ -402,23 +400,23 @@ \subsubsection{Size reduction} If we can reduce the shuffle size used in Whisk and still prove it secure, then we expect to see some reduction in the size overhead on the blockchain. We first set our focus on Curdleproofs, as this is the protocol we have modified directly. -As mentioned in~\autoref{subsec:related-work-whisk}, the size of Curdleproofs is $18+10 \log(\ell+4)\mathbb{G}$, $7\mathbb{F}$. +As mentioned in~\autoref{subsec:related-work-whisk}, 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, see Appendix~\ref{sec:appendix-thm1proof}, we show that CAAUrdleproofs is $\mathcal{O}(\log n)$, which is the same as Curdleproofs. However, as discussed in~\autoref{subsec:approach-CAAUrdleproofs}, CAAUrdleproofs'~\gls{ipa} proofs use $\lceil \log n \rceil$ recursive rounds. -This means that the size of CAAUrdleproofs must be $18+10 \lceil\log(\ell+4)\rceil\mathbb{G}$, $7\mathbb{F}$. +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. +The CAAUrdleproofs modification can still reduce the overall block size overhead. By using the overhead calculation described by Whisk on CAAUrdleproofs, it measures a block overhead 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 provided calculation of the block overhead is provided as 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. }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 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). \item A Discrete Logarithm Equivalence Proof on the ownership of the elected proposer commitment (two G1 points, two Fr scalars $\Rightarrow2\cdot48+2\cdot32=160$ bytes). diff --git a/report/src/sections/05-experimental-protocol.tex b/report/src/sections/05-experimental-protocol.tex index 8319b1e..58da841 100644 --- a/report/src/sections/05-experimental-protocol.tex +++ b/report/src/sections/05-experimental-protocol.tex @@ -17,22 +17,19 @@ \subsection{CAAUrdleproof}\label{sec:CAAUrdleproof-experiment} In CAAUrdleproofs, we will test the protocol with $\ell=\{8,9,\dots,256\}$. -Since Curdleproofs is unable to run benchmarks, unless the shuffle size is a power of two, those benchmarks will be run on values $\ell=\{8,16,32,64,128,256\}$. +Since Curdleproofs is unable to run benchmarks, unless the shuffle size is a power of two, those benchmarks will be run on values $\ell=2^N$, where $N=\{3,4,5,6,7,8\}$. \subsection{Shuffle security}\label{subsec:experimental-protocol-shuffle-security} -In this experiment we run the shuffle protocol with varying shuffle sizes and varying number of adversarial tracked ciphertexts. +In this experiment, we run the shuffle protocol with varying shuffle sizes and varying numbers of adversarial tracked ciphertexts. The purpose of this experiment is to find the lowest possible shuffle size that is still secure against adversarial tracking. -We therefore run the experiment with shuffle sizes, $\ell$, between 64 and 128. +We therefore run the experiment with shuffle sizes,~$\ell$, between 32 and 512. For the number of adversarial tracked ciphertexts, we use the values $\alpha=\{1/2,1/3,1/4\}$ -Because Curdleproofs is meant to be used in an Ethereum setting, all the experiments were done with a maximum of 8192 shuffles. +Because Curdleproofs is meant to be used in an Ethereum setting, a maximum of 8,192 shuffles is available. +Though, we will keep running the shuffling experiments until they are deemed secure. Also, the experiments shuffle over a set of 16,384 ciphertexts. Both of these numbers come from the Ethereum Whisk proposal~\cite{Whisk2024}. - - -Every experiment is run 1000 times to avoid statistical uncertainty. -As done by the shuffle authors~\cite{cryptoeprint:2022/560}, we will denote the 20th, 40th, 60th, 80th, and 100th percentile on when the shuffle is deemed secure by the experimental runs. - +Every experiment is run 1000 times to avoid statistical uncertainty. \ No newline at end of file diff --git a/report/src/sections/06-results.tex b/report/src/sections/06-results.tex index 5035834..bc12eaf 100644 --- a/report/src/sections/06-results.tex +++ b/report/src/sections/06-results.tex @@ -13,7 +13,7 @@ \subsection{Proving and Verifying Times}\label{subsec:results:provingverifying} \end{figure*} 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. +Curdleproofs was only run with a shuffle size $\ell = 2^N$, where $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. @@ -54,14 +54,14 @@ \subsection{Shuffle security}\label{subsec:Shuffle-security} \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. -Therefore, the results of the experiment also find $T_H=T-\beta$. +In Ethereum, each shuffling phase is limited to 8,192 shuffles, meaning that the maximum number of honest shuffles that can be used is 8192. +Therefore, the results of the experiment actually 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. -The rest could then be the number of dishonest shuffles,~$\beta$. +The rest is therefore the maximum number of dishonest shuffles allowed,~$\beta$. 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 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. +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 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. @@ -81,7 +81,7 @@ \subsection{Shuffle security}\label{subsec:Shuffle-security} 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. +This spike is not present for the other two $\alpha$ values, and is likely due to the probabilistic nature of the shuffling method. Another thing that is notable is that in the setting of Ethereum, the maximum number of shuffles available is 8192. This means that in the cases where more than the 8192 shuffles were necessary to make the shuffle secure, the shuffle would not have been secure within the Ethereum setting. diff --git a/report/src/sections/07-discussion.tex b/report/src/sections/07-discussion.tex index c5e29f4..4aa8f22 100644 --- a/report/src/sections/07-discussion.tex +++ b/report/src/sections/07-discussion.tex @@ -39,12 +39,12 @@ \subsection{Shuffle Security}\label{subsec:Discution-Shuffle-security} 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. +As seen in~\autoref{fig:shufflesecurity} you would also only need a third of the 8192 shuffles to be honest to get within the 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 being only 72.33\% of the current size for Curdleproofs. This would result in saving $\sim 12.11$GB 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. +Some other things to keep in mind when deciding on how many honest shuffles should be necessary to make the shuffle secure are that there are other factors that can affect the security of the blockchain. One of such factors is some of the known attacks that take advantage of controlling a large number of validators. Attacks like the $\geq50\%$ stake attack and the $33\%$ finality attack~\cite{EthereumAttackDefense2024} take advantage of controlling a large number of validators in order to negatively affect the blockchain system. Because of attacks like these, which rely on controlling a large number of validators, we would recommend, when evaluating how many honest shuffles are necessary to make the shuffle secure; one should also take into account how many honest validators are necessary to make the blockchain secure. @@ -53,7 +53,7 @@ \subsection{Shuffle Security}\label{subsec:Discution-Shuffle-security} 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$. +From the results, in~\autoref{fig:shufflesecurity}, 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. diff --git a/report/src/sections/08-conclusion.tex b/report/src/sections/08-conclusion.tex index d2d2b09..180ae2f 100644 --- a/report/src/sections/08-conclusion.tex +++ b/report/src/sections/08-conclusion.tex @@ -1,12 +1,12 @@ \section{Conclusion}\label{sec:conclusion} -After looking into the \glspl{zk} \glspl{ssle} protocol Whisk and the Curdleproofs protocol, we found that there was still was room for improvement in the Curdleproofs protocol. +After looking into the \gls{zk} \gls{ssle} protocol Whisk and the Curdleproofs protocol, we found that there was still room for improvement in the Curdleproofs protocol. We saw the strict requirement of the shuffle size being a power of two as a limitation, and we wanted to remove this limitation to try to reduce the block overhead related to the protocol. -To do this, we looked at Springproofs which allows for \glspl{ipa} to be of any size. -Through combining the Curdleproofs protocol with the flexiblility of Springproofs, we made the CAAUrdleproofs protocol. -The implementation of the CAAUrdleproofs protocol, is a modified version of the Curdleproofs protocol that allows for any shuffle size. +To do this, we looked at Springproofs, which allows for \glspl{ipa} to be of any size. +Through combining the Curdleproofs protocol with the flexibility of Springproofs, we made the CAAUrdleproofs protocol. +The implementation of the CAAUrdleproofs protocol is a modified version of the Curdleproofs protocol that allows for any shuffle size. Through our experiments, we found that the CAAUrdleproofs protocol has similar proving and verifying times to the Curdleproofs protocol when the shuffle size is a power of two. But for any shuffle size that is not a power of two, the CAAUrdleproofs protocol has a performance advantage. @@ -16,7 +16,7 @@ \section{Conclusion}\label{sec:conclusion} We have shown the security through an experiment inspired by~\cite{cryptoeprint:2022/560}. Here we found that the shuffle size could be reduced to 80 and still be secure, also considering the domain in which the protocol is intended. -Using this, we see a block overhead of just 72.33\% the size compared to Curdleproof. +Using this, we see a block overhead of just 72.33\% the size compared to Curdleproofs. Hence, we have shown CAAUrdleproofs to be an optimized modification of Curdleproofs, as it allows for more flexibility in the choice of shuffle size. diff --git a/report/src/sections/appendix/04-shuffling-times.tex b/report/src/sections/appendix/04-shuffling-times.tex index 84b90f3..7064a62 100644 --- a/report/src/sections/appendix/04-shuffling-times.tex +++ b/report/src/sections/appendix/04-shuffling-times.tex @@ -1,4 +1,7 @@ +\clearpage \section{Shuffling results}\label{sec:shuffling-results} +Here we present the results of the shuffling times given different shuffling size values. +The results can be seen in~\autoref{fig:shufflespeed} \begin{figure}[!htb] \includegraphics[width=0.99\columnwidth]{figures/results/shufflingtime} \caption{The shuffling times at each benchmark}% diff --git a/report/src/setup/acronyms.tex b/report/src/setup/acronyms.tex index 837543a..d84cfdb 100644 --- a/report/src/setup/acronyms.tex +++ b/report/src/setup/acronyms.tex @@ -27,7 +27,7 @@ \newacronym{sameperm}{SamePerm}{Same Permutation} \newacronym{samemsm}{SameMSM}{Same Multiscalar Multiplication} \newacronym{rrc}{RRC}{re-randomizable commitment} -\newacronym{eth}{ETH}{Ether} +\newacronym{eth}{ETH}{ether} \newacronym{grandprod}{GrandProd}{Grand Product} \newacronym{dlipa}{DL IPA}{Discrete-Logarithm Inner Product Argument} \newacronym{wipa}{WIPA}{Weighted Innner Product Argument}