-
Notifications
You must be signed in to change notification settings - Fork 3
Expand file tree
/
Copy pathchap02-sec03.tex
More file actions
59 lines (53 loc) · 5.63 KB
/
Copy pathchap02-sec03.tex
File metadata and controls
59 lines (53 loc) · 5.63 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
% !TEX root = ../zeth-protocol-specification.tex
\section{Generating the inputs of the $\mix$ function (\inp{\mix})}\label{zeth-protocol:mix-inp}
In the following section, we assume that the system is initialized. In other words, we assume that a ledger $\ledger$ is available (i.e.~an \ethereum~network is operated by a set of miners), the $\mixer$ contract is deployed on $\ledger$. Likewise, we assume that the public parameters $\pparams_{\zksnark} \gets \zksnark.\kgen(\secparam, \RELCIRC)$ are available to $\mixer$ and to all parties willing to call the $\mix$ function of $\mixer$. Furthermore, we assume that there exists a set of \ethereum~and \zeth~users, and that the \emph{payment address} of each \zeth~user is easily discoverable. In the rest of this section, the set of \emph{payment addresses} discovered by a zeth user $\zparty{U}$ is represented as a list attribute $\zparty{U}.\keystore$ indexed by usernames.
\medskip
In order for $\zparty{U}$ to transact via \zeth, $\zparty{U}$ needs to create an object $\inp{\mix}$ of type $\mixInputDType$ to pass to the $\mix$ function of $\mixer$:
\begin{enumerate}
\item Create an object $\priminputs$ of type $\primInputDType$ to represent the primary input, and an object $\auxinputs$ of type $\auxInputDType$ to represent the auxiliary input, where:
\begin{enumerate}
\item $\priminputs.\mkroot \in \rootset$, where $\rootset$ is the set of \emph{all} Merkle roots corresponding to one of the state of the Merkle tree on $\mixer$ containing \emph{all} the commitments to the input notes, in $\auxinputs.\jsins{}$, in its set of leaves.
\item $\auxinputs.\znotes{j}.\noter \sample \BB^{\noterLen}, \forall j \in [\jsout]$, and $\auxinputs.\pphi \sample \BB^{\phiLen}$
\item The public values $(\auxinputs.\vin, \auxinputs.\vout) \in {(\BB^{\zvalueLen})}^{2}$, $\auxinputs.\znotes{j}.\notev$ and $\auxinputs.\znotes{j}.\apk\ \forall j \in [\jsout]$ are all set by the sender, $\zparty{U}$, as desired as long as they satisfy the \gls{joinsplit-eq}.
\item All attributes of the $\priminputs$ and $\auxinputs$ objects should be derived as specified in the statement (see~\cref{zeth-protocol:statement}), alongside a signature hash ($\auxinputs.\hsig$) that is generated as the hash of the nullifiers and a one-time signing verification key (non-malleability, see~\cref{appendix:trnm}), using the desired signature scheme $\otsigscheme$ (see~\cref{instantiation:otsig}):
\begin{align}
& (\sk_{\otsig}, \vk_{\otsig}) = \otsigscheme.\kgen(\secparam) \label{zeth-protocol:otsig-generation} \\
& \auxinputs.\hsig = \crhhsig{\indexedset{\auxinputs.\jsins{i}.\nf{}}{i \in [\jsin]}, \vk_{\otsig}}
\end{align}
\item $\inp{\mix}.\primInp \gets \priminputs$
\end{enumerate}
\begin{notebox}
If one of the attributes of $\priminputs$ and $\auxinputs$ is not correctly generated, then the proof of computational integrity generated in the next step will be rejected on $\mixer$, and the state of $\mixer$ will not be modified.
\end{notebox}
\item Generate a zk-SNARK proof \zkp~to prove, in zero-knowledge, that the relation $\RELCIRC$ (\cref{zeth-protocol:statement}) holds on the primary and auxiliary inputs, using the desired zk-SNARK scheme $\zksnark$ (see~\cref{instantiation:zksnark}):
\begin{enumerate}
\item $\zkp \gets \zksnark.\prover(\pparams_{\zksnark}, \priminputs, \auxinputs)$
\item $\inp{\mix}.\zkproof \gets \zkp$
\end{enumerate}
\item Encrypt all the $\auxinputs.\znotes{}$ using the recipient's \emph{payment address}, using the encryption scheme $\encscheme$ (see~\cref{instantiation:enc}).
\begin{enumerate}
\item For all $j \in [\jsout]$, do:
\begin{align*}
& \ct_j \gets \encscheme.\enc(\auxinputs.\znotes{j}, \zparty{U}.\keystore[\varstyle{recipient}_j].\pubaddr.\pkenc)
\end{align*}
\item $\inp{\mix}.\ciphers \gets \indexedset{\ct_j}{j \in [\jsout]}$
\end{enumerate}
\item Generate a signature $\otsSigma$ on the inputs of the \mix~function, in order to prevent any malleability attacks~(c.f.~\cref{appendix:trnm}), using the desired signature scheme $\otsigscheme$ (see~\cref{instantiation:otsig}):
\begin{enumerate}
\item\label{zeth-protocol:mix-inp:create-otsig} Using the one-time signature keypair generated in~\cref{zeth-protocol:otsig-generation}, do:
\begin{align*}
& \datatobesigned = \eparty{S}.\addr \concat \inp{\mix}.\primInp \concat \inp{\mix}.\zkp \concat \inp{\mix}.\ciphers \\
& \otsSigma = \otsigscheme.\sig(\sk_{\otsig}, \crhots{\datatobesigned})
\end{align*}
\item $\inp{\mix}.\otssig \gets \otsSigma$
\item $\inp{\mix}.\otsvk \gets \vk_{\otsig}$
\end{enumerate}
Here, $\eparty{S}.\addr$ represents the address of the $\ethereum{}$ user $\eparty{S}$ who must sign the transaction (see~\cref{zeth-protocol:create-tx}). In general, this is likely to be owned by the holder $\zparty{U}$ of the $\zeth{}$ notes to be spent, but this is not a requirement.
\end{enumerate}
\begin{remark}\label{zeth-protocol:mix-inp:otsig-for-dispatch-call}
\cref{zeth-protocol:process-tx:dispatch-call} describes a situation in which the proof data $\inp{\mix}.\zkp$ is not available (having been verified by some external mechanism). In such cases, $\datatobesigned$ in \cref{zeth-protocol:mix-inp:create-otsig} \MAY{} be replaced with:
\[
\datatobesigned = \eparty{S}.\addr \concat \inp{\mix}.\primInp \concat \inp{\mix}.\ciphers
\]
This modification, mentioned here for completeness, \MUSTNOT{} be used except as described in \cref{zeth-protocol:process-tx:dispatch-call}.
\end{remark}