chap01-sec04.tex

% !TEX root = ../zeth-protocol-specification.tex

\section{Decentralized Anonymous Payment schemes (DAP)}\label{preliminaries:dap}

\zeth~\cite{zethpaper} is a Decentralized Anonymous Payment scheme (\dapscheme)~\cite[Section 3]{sasson2014zerocash} defined on top of an \ethereum~ledger~\ledger. A \dapscheme~is a tuple of polynomial-time algorithms $\dapscheme = (\setup,\ \genadd,\ \sendtx,\ \verifytx,\ \receive)$ that manipulate (\emph{create}, \emph{spend}) data objects called \notes. These objects are bound to a given owner and have a value $\notev$ attribute (see~\cref{zeth-protocol:zeth-data-types}).

\begin{description}
    \item[System Setup] The algorithm $\setup$ takes the security parameter \secpar~as input and generates the public parameters $\pparams$. The algorithm $\setup$ is executed by a trusted party. The resulting public parameters $\pparams$ are published and made available to all parties.
    \item[Creating \zeth~addresses] The algorithm $\genadd$ takes as input the public parameters $\pparams$ and generates a new $\dapscheme$ address object $\addr = \{\pubaddr: \addr_\pk, \privaddr: \addr_\sk\}$. More precisely, $\addr_\pk$ is an object referred to as the ``payment address'' (\cref{preliminaries:tab:dap-payaddr}), and $\addr_\sk$ is an object referred to as the ``private address'' (\cref{preliminaries:tab:dap-privaddr})~\cite{zcashprotocol}.
    \item[Transfer notes] The algorithm $\sendtx$ is used to transfer some public input \vin~as well as the value of a set of input (``old'') \notes~into a set of output (``new'') \notes~as well as some public output value \vout. The inputs $\notes$ are marked as ``consumed'' (alternatively, we say that the input \notes~are ``spent''). $\sendtx$ takes as inputs the public parameters $\pparams$, the input value and the input (``old'') $\notes$ to be transferred, as well as the Merkle root and the Merkle authentications paths of the commitments to the input $\notes$, the ``spending keys'' related to the input $\notes$, the output value to create and the ``payment addresses'' for the output (``new'') $\notes$. If the \gls{joinsplit-eq} is satisfied, the algorithm returns the new $\notes$ and the corresponding \ethereum~transaction $\tx$, else it returns $\perp$.
    \item[Verifying transactions] The algorithm $\verifytx$ checks the validity of a transaction. It takes as inputs the public parameters $\pparams$, a transaction and the current ledger $\ledger$ and outputs a bit equal $1$ iff the transaction is valid, $0$ otherwise.
    \item[Receiving notes] The algorithm $\receive$ scans the ledger $\ledger$ and retrieves unspent $\notes$ paid to a particular user address. It takes as input the recipient address key pair $\{\pubaddr: \addr_\pk, \privaddr: \addr_\sk\}$ and the current ledger $\ledger$ and outputs the set of (unspent) received $\notes$.
\end{description}

\begin{notebox}
    In the rest of this document, we will refer to a \emph{Zeth user} $\zparty{U}$ as a person, modeled as an object, holding one \zeth~address (object attribute), and thus holding a \emph{private address}, $\addr_\sk$. We denote by $\zparty{U}.\addr$ the \zeth~address of $\zparty{U}$ derived from $\addr_\sk$, and which allows $\zparty{U}$ to be the recipient of payments via $\zeth$, and to send funds via \zeth. Importantly, \emph{not all \ethereum~users are \zeth~users, and vice-versa!}
\end{notebox}

\begin{table}[H]
\centering
\begin{tabular}{ccc}
    Field           & Description\\ \toprule
    $\apk$        & The \emph{paying key}\\ \midrule
    $\pkenc$      & The \emph{transmission key}\\\bottomrule
\end{tabular}
\caption{``Payment address'', $\addr_\pk$, of a $\dapscheme$ address}\label{preliminaries:tab:dap-payaddr}
\end{table}

\begin{table}[H]
\centering
\begin{tabular}{cc}
    Field           & Description\\ \toprule
    $\ask$        & The \emph{spending key}\\ \midrule
    $\skenc$      & The \emph{receiving key}\\\bottomrule
\end{tabular}
\caption{``Private address'', $\addr_\sk$, of a $\dapscheme$ address}\label{preliminaries:tab:dap-privaddr}
\end{table}

\zeth~leverages zk-SNARKs (\cref{preliminaries:zk-snark}) and the possibility to deploy smart-contracts to specify privacy-preserving state transitions altering the \ethereum~state \wstate (\cref{preliminaries:ethereum}).
As such, \zeth~defines a smart-contract, $\mixer$, that keeps track of the set of $\zethnotes$ (\cref{zeth-protocol:zeth-data-types}) in a committed form, stored in a Merkle tree; and which verifies the validity of the state transitions generated by the \zeth~users. As such a \zeth~\dapscheme~is entirely determined by $\mixer$, the instance of the mixer smart-contract deployed on the \ethereum~ledger.
State transitions are executed on-chain by calling the $\mix$ function of $\mixer$, which implements the algorithm $\verifytx$ of $\dapscheme$, and which modifies $\wstate$ iff the transaction is deemed valid.

\begin{notebox}
We denote by $\inp{\mix}$ the inputs taken by the $\mix$ function defined on \mixer. Let $\zdata$ be the value of the $\data$ field of an \ethereum~transaction such that:
\[
    \zdata = \funcSelec{\mix} \concat \inp{\mix}
\]

Then, we define $\tx_\mix$ as being the \ethereum~transaction object returned by $\sendtx$ such that:
\[
    \tx_\mix.\tto = \mixer.\addr \land \tx_\mix.\data = \zdata
\]

Importantly, when it is clear from context, we will omit the function selector from the definition of \zdata, and only assume that \zdata = \inp{\mix}.
\end{notebox}