jude/Riskless
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Diagrams

Browse Source
This commit is contained in:
jude 2023-04-28 14:33:54 +01:00
parent a7daf39918
commit 9d01d3bd38
2 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
whitepaper/Dissertation.pdf
View File

Binary file not shown.

28
whitepaper/Dissertation.tex
View File

@ -995,37 +995,37 @@ We can apply the Fiat-Shamir heuristic to make proofs of zero non-interactive \c
\draw [very thick] (V) -- (6,-15);
\draw [very thick] (P2)-- (12,-15);
\draw [->,very thick] (0,-3)--node [auto] {Protocol~\ref*{protocol1}}++(6,0);
\draw [->,very thick] (0,-3)--node [auto] {\hyperref[protocol1]{Protocol~\ref*{protocol1}}}++(6,0);
\draw [->,very thick] (6,-3)--(12,-3);
\node[draw=blue!50,rectangle] at (0,-2) {Reinforce regions};
\draw [<->,very thick] (12,-4)-- node[above] {Protocol~\ref*{protocol0} (neighbouring counts)} ++ (-12,0);
\draw [<->,very thick] (12,-4)-- node[above] {\hyperref[protocol0]{Protocol~\ref*{protocol0}} (neighbouring counts)} ++ (-12,0);
\node[draw=blue!50,rectangle] at (0,-5) {Attack Player 2};
\draw [->,very thick] (0,-6)--node [auto] {Protocol~\ref*{protocol4}}++(6,0);
\draw [->,very thick] (0,-6)--node [auto] {\hyperref[protocol4]{Protocol~\ref*{protocol4}}}++(6,0);
\draw [->,very thick] (6,-6)--++(6,0);
\node[draw=blue!50,rectangle] at (12,-7) {Send defence};
\draw [->,very thick] (12,-8)--node [above] {Protocol~\ref*{protocol4}}++(-6,0);
\draw [->,very thick] (12,-8)--node [above] {\hyperref[protocol4]{Protocol~\ref*{protocol4}}}++(-6,0);
\draw [->,very thick] (6,-8)--++(-6,0);
\path (0,-9)-- node[above] {Protocol~\ref*{protocol2} (resolve dice)} ++ (12,0);
\path (0,-9)-- node[above] {\hyperref[protocol2]{Protocol~\ref*{protocol2}} (resolve dice)} ++ (12,0);
\draw [<->,very thick] (0,-9)--++ (6,0);
\draw [<->,very thick] (6,-9)--++ (6,0);
\path (0,-10)-- node[above] {Protocol~\ref*{protocol4} (prove maintained ownership)} ++ (12,0);
\path (0,-10)-- node[above] {\hyperref[protocol4]{Protocol~\ref*{protocol4}} (prove maintained ownership)} ++ (12,0);
\draw [<->,very thick] (0,-10)--++ (6,0);
\draw [<->,very thick] (6,-10)--++ (6,0);
\node[draw=blue!50,rectangle] at (0,-11) {Fortify};
\draw [->,very thick] (0,-12)--node [auto] {Protocol~\ref*{protocol3}}++(6,0);
\draw [->,very thick] (0,-12)--node [auto] {\hyperref[protocol3]{Protocol~\ref*{protocol3}}}++(6,0);
\draw [->,very thick] (6,-12)--(12,-12);
\draw [<->,very thick] (12,-13)-- node[above] {Protocol~\ref*{protocol0} (neighbouring counts)} ++ (-12,0);
\draw [<->,very thick] (12,-13)-- node[above] {\hyperref[protocol0]{Protocol~\ref*{protocol0}} (neighbouring counts)} ++ (-12,0);
\path (0,-14)--node [auto] {Protocol~\ref*{protocol4} (prove non-negative)}++(12,0);
\path (0,-14)--node [auto] {\hyperref[protocol4]{Protocol~\ref*{protocol4}} (prove non-negative)}++(12,0);
\draw [->,very thick] (0,-14)--++(6,0);
\draw [->,very thick] (6,-14)--++(6,0);
@ -1152,10 +1152,10 @@ All measurements were taken on Brave 1.50.114 (Chromium 112.0.5615.49) 64-bit, u
\begin{tabularx}{\hsize}{c *8{>{\Centering}X}}
\toprule
\multirow{2}{*}{Modulus} &
\multicolumn{2}{c}{Proof-of-zero} &
\multicolumn{2}{c}{\hyperref[protocol0]{Protocol~\ref*{protocol0}}} &
\multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 24$} &
\multicolumn{2}{c}{BCDG Range with $t = 24$} &
\multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol4}} with $t = 24$}
\multicolumn{2}{c}{\hyperref[protocol4]{Protocol~\ref*{protocol4}} with $t = 24$}
\tabularnewline
\cmidrule(l){2-3}\cmidrule(l){4-5}\cmidrule(l){6-7}\cmidrule(l){8-9}
& Prover & Verifier & Prover & Verifier & Prover & Verifier & Prover & Verifier \\
@ -1174,7 +1174,7 @@ All measurements were taken on Brave 1.50.114 (Chromium 112.0.5615.49) 64-bit, u
\label{table3}
\begin{tabularx}{\hsize}{c *8{>{\Centering}X}}
\toprule
\multirow{2}{*}{Modulus} & \multicolumn{2}{c}{Proof-of-zero non-interactive} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 24$} & \multicolumn{2}{c}{BCDG Range with $t = 24$} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol4}} with $t = 24$}
\multirow{2}{*}{Modulus} & \multicolumn{2}{c}{\hyperref[protocol0]{Protocol~\ref*{protocol0}}} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 24$} & \multicolumn{2}{c}{BCDG Range with $t = 24$} & \multicolumn{2}{c}{\hyperref[protocol4]{Protocol~\ref*{protocol4}} with $t = 24$}
\tabularnewline
\cmidrule(l){2-3}\cmidrule(l){4-5}\cmidrule(l){6-7}\cmidrule(l){8-9}
& JSON & with LZ-String & JSON & with LZ-String & JSON & with LZ-String & JSON & with LZ-String \\
@ -1207,7 +1207,7 @@ I propose some ideas which could build off the content here.
\subsection{Larger scale games}
Many other games exist that the ideas presented could be applied to. Games of larger scale with a similar structure, such as Unciv, could benefit from P2P networking implemented in a similar manner. In particular, \hyperref[protocol1]{Protocol~\ref*{protocol2}} would form an intrinsic part of such games.
Many other games exist that the ideas presented could be applied to. Games of larger scale with a similar structure, such as Unciv, could benefit from P2P networking implemented in a similar manner. In particular, similar protocols to \hyperref[protocol4]{Protocol~\ref*{protocol4}} would form an intrinsic part of such games, as they have a similar graph structure which requires guarantees of adjacency for many actions.
The downsides of this are that the complexity of P2P networking is far greater than in a centralised model. This would be a considerable burden on the developers, and could hurt the performance of such a game. Additionally, some modern routers no longer support NAT hole-punching or UPnP due to security concerns \cite{upnp}, which makes accessing P2P services more difficult for end users.
@ -1243,7 +1243,7 @@ Using a language that can interact with the operating system would have further
\subsection{Resources}
The P2P implementation requires more processing power and more bandwidth on each peer than a client-server implementation would. This is the main limitation of the P2P implementation. The program ran in a reasonable time, using a reasonable amount of resources on the computers I had access to, but these are not representative of the majority of people. Using greater processing power increases power consumption, which is undesirable. In a client-server implementation, the power consumption should be lower than the P2P implementation presented as no processing time is spent validating proofs or using the Paillier cryptosystem, which is less efficient than the hybrid cryptosystems used in standard online communication.
The P2P implementation requires more processing power and more bandwidth on each peer than a client-server implementation would. This is the main limitation of the P2P implementation. The program ran in a reasonable time, using a reasonable amount of resources on the computers I had access to, but these are not representative of the majority of computers in use today. Using greater processing power increases power consumption, which is undesirable. In a client-server implementation, the power consumption should be lower than the P2P implementation presented as no processing time is spent validating proofs or using the Paillier cryptosystem, which is less efficient than the hybrid cryptosystems used in standard online communication.
\bibliography{Dissertation}