Introduction

report/src/bib/main.bib

@@ -223,4 +223,12 @@ @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}
+}
+
+@article{EthereumAttackDefense2024,
+    title        = {Ethereum proof-of-stake attack and defense},
+    author       = {ethereum.org},
+    year         = {2024},
+    note         = {Accessed: 22-10-2024},
+    url = {https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/attack-and-defense/}
 }

report/src/sections/01-introduction.tex

@@ -3,5 +3,33 @@
 \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 on entities called validators.
+Though, previous work from Heimbach et al., confirmed also by our 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}.
+Whisk is a Single Secret Leader Election 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}.
+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.
+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 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 when CAAUrdleproofs is still secure.
+
+Working with this led to the following contributions:
+\begin{itemize}
+    \item We have successfully modified Curdleproofs, using the Springproofs framework~\cite{zhang2024springproofs}, to allow flexibility when choosing the shuffle size.
+    \item We have implemented CAAUrdleproofs and run experiments on both protocols, showing that CAAUrdleproofs has potential to be faster and smaller in size compared to Curdleproofs.
+    \item We have experimentally provided argumentation that CAAUrdleproofs is still secure when lowering the size of shuffled elements.
+\end{itemize}
 
 

report/src/sections/07-discussion.tex

@@ -47,9 +47,9 @@ \subsection{Shuffle Security}\label{subsec:Discution-Shuffle-security}
 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.
+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.
 
 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.