\section{Skeletons}
\label{sec:skeletons}
Now we have developed Parallel Arrows far enough to define some useful algorithmic skeletons that abstract typical parallel computations. While there are many possible skeletons to implement, we demonstrate the expressive power of PArrows here using four |map|-based and three toplogical skeletons.
%%% \FloatBarrier
\subsection{|map|-based skeletons}
\label{sec:map-skeletons}
The essential differences between the mapping skeletons presented here are in terms of order of evaluation and work distribution but still provide the same semantics as a sequential |map|.

\paragraph{Parallel |map| and laziness.}
The |parMap| skeleton (Figs.~\ref{fig:parMapImg},~\ref{fig:parMap}) is probably the most common skeleton for parallel programs. We can implement it with |ArrowParallel| by repeating an Arrow |arr a b| and then passing it into |parEvalN| to obtain an Arrow |arr [a] [b]|.
Just like |parEvalN|, |parMap| traverses all input Arrows as well as the inputs.
Because of this, it has the same restrictions as |parEvalN| as compared to |parEvalNLazy|. So it makes sense to also have a |parMapStream| (Figs.~\ref{fig:parMapStreamImg},~\ref{fig:parMapStream}) which behaves like |parMap|, but uses |parEvalNLazy| instead of |parEvalN|. Implementing these skeletons is straightforward as in Appendix \ref{app:omitted} in Figs.\ref{fig:parMap} and \ref{fig:parMapStream}.

\begin{figure}[thb]
%farm
\includegraphics[scale=0.7]{images/farm}
\caption{|farm| depiction.}
\label{fig:farmImg}

\begin{code}
farm :: (ArrowParallel arr a b conf,
	ArrowParallel arr [a] [b] conf, ArrowChoice arr) =>
	conf -> NumCores -> arr a b -> arr [a] [b]
farm conf numCores f =
	unshuffle numCores >>>
	parEvalN conf (repeat (mapArr f)) >>>
	shuffle
\end{code}
\caption{|farm| definition.}
\label{fig:farm}

%farmChunk
\includegraphics[scale=0.7]{images/farmChunk}
\caption{|farmChunk| depiction.}
\label{fig:farmChunkImg}
\end{figure}

\paragraph{Statically load-balancing parallel |map|.}
Our |parMap| spawns every single computation in a new thread (at least for the instances of |ArrowParallel| we presented in this paper). This can be quite wasteful and a statically load-balancing |farm| (Figs.~\ref{fig:farmImg},~\ref{fig:farm}) that equally distributes the workload over |numCores| workers seems useful.
The definitions of the helper functions |unshuffle|, |takeEach|, |shuffle| (Fig.~\ref{fig:edenshuffleetc}) originate from an Eden skeleton\footnote{Available on Hackage under \url{https://hackage.haskell.org/package/edenskel-2.1.0.0/docs/src/Control-Parallel-Eden-Map.html}.}.

%\paragraph{Lazy statically load-balancing parallel map}
Since a |farm|  is basically just |parMap| with a different work distribution, it has the same restrictions as |parEvalN| and |parMap|. We can, however, define |farmChunk| (Figs.~\ref{fig:farmChunkImg},~\ref{fig:farmChunk}) which uses |parEvalNLazy| instead of |parEvalN|. It is basically the same definition as for |farm|, but with |parEvalNLazy| instead of |parEvalN|.

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "main"
%%% End:


%\vspace{-5pt}
\section{Related Work}
\label{sec:related}

We use natural language techniques for predicting code.
In this section, we review some literature on language models and
neural network based language models.

\subsection{Traditional Language Models}
Statistical models of languages have been used extensively in various natural
language processing tasks. One of the simplest such models proposed is the
$n$-gram model, where the frequencies of consecutive $n$ tokens are used to
predict the probability of occurence of a sequence of tokens. The frequencies of
such $n$-grams are obtained from a corpus, and are smoothed by various
algorithms such as Kneser-Ney smoothing~\cite{ref:kneser-ney} to account for
sparsity of $n$-grams. Such models can be easily extended to code completion,
by modeling each token as a word and doing $n$-gram analysis over a
codebase. However, such models do not capture
the high fraction of unknown tokens from variable and function names very well.
%used for code completion considering the high fraction of {\tt UNKNOWN} tokens
%in codes. For example, even in a simple case such as {\tt for(int SOMEVAR = 0;
%SOMEVAR < EXPRESSION; SOMEVAR++)}, the token {\tt SOMEVAR} can be arbitrary, and
%{\tt EXPRESSION} can consist of multiple tokens. Also, it has been shown that
%neural network based language models far outperform such traditional language
%models. Hence, in our work, we only consider neural network based language
%models.

\subsection{Word Vector Embeddings and Neural Network Language Models (NNLM)}
In their seminal work, Bengio et al.~\cite{ref:embedding} first propose a
vector embedding space for words for constructing a language model,
that significantly outperforms traditional $n$-gram based
approaches. Their proposal maps each word to a vector and expresses the
probability of a token as the result of a multi-layer neural network on the
vectors of a limited window of neighboring words. T. Mikolov
et al.~ \cite{ref:regularities} show that such models can capture word-pair relationships
(such as ``{\em king} is to {\em queen} as {\em man} is to {\em woman}'') in
the form of vector operations (i.e., $v_{\text king} -
v_{\text queen} = v_{\text man} - v_{\text woman}$). To distinguish such models
from {\it recurrent} models, we
call them {\it feed-forward} neural network language models.
We use the same concept in our token-embedding. We found singificant clustering
of similar tokens, such as {\tt uint8\_t} and {\tt uint16\_t}, but were unable
to fund vector relationships.
%We use the same concept in our token-embeddings, where we attempt to predict
%probabilities of the next token depending on the token-vectors of a fixed window
%of prior tokens.
%We were able to observe significant clustering in the word
%vectors of similar tokens (e.g., vectors of {\tt uint8\_t} and {\tt uint16\_t}
%are very similar). However, we were {\it unable} to find vector relationships
%between tokens such as those discussed above.

Later, such feed-forward NNLMs have been extended by Mikolov et
al.~\cite{ref:mikolov:wvec} where they propose the continuous
bag-of-words (CBOW), and the skip-gram. In CBOW, the probability of a token is
obtained from the average of vectors of the neighboring tokens, whereas in
skip-gram model the probabilities of the neighboring tokens is obtained from the
vector of a single token. The main advantage of such models is their
simplicity, which enables them to train
% relative to a multi-layer feed-forward network, which enables them to be trained
faster on billion-word corpuses. However, in our case, the size of data was not
so huge, and we could train even a 4-layer model in 3 days.

\subsection{RNN Language Models}
\label{sec:rel:rnnlm}
A significant drawback of feed-forward neural network based language models is
their inability to consider dependencies longer than the window size. To fix
this shortcoming, Mikolov et al. proposed a recurrent neural network based
language model~\cite{ref:rnnlm}, which associates a cell with a hidden state
at each position, and updates the state with each token. Subsequently, more
advanced memory cells such as LSTM~\cite{ref:lstm} and GRU~\cite{ref:gru} have
been used for language modeling tasks. More sophsticated models such as
tree-based LSTMs ~\cite{ref:treelstm} have also
been proposed. We experimented with using GRUs in our setup, but surprisingly
did not find them to be competitive with feed-forward networks.

\subsection{Attention Based Models}
\label{sec:attn}
Recently, neural network models with {\it attention}, i.e., models that weigh
different parts of the input differently have received a lot of attention (pun
intended) in areas such as image captioning~\cite{ref:showattendtell} and
language translation~\cite{ref:nmt,ref:nmt2}. In such models, the actual task of
prediction is separated into two parts: the attention mechanism which
``selects'' the part of input that is important, and the actual prediction
mechanism which predicts the output given the weighted input. We found an
attention based feed-forward model to be the best performing model among the
ones we considered.

\subsection{Code Completion}
\label{sec:code-completion}
Frequency, association and matching neighbor based
approaches~\cite{ref:learningexamples} are used to improve predictions of IDEs such
as Eclipse.
Our learning approach, on the other hand, attempts to automatically
learn such rules and patterns.


\subsection{Knowledge bases as graphs}

\subsubsection{Introduction}

We can consider each fact to be a mini graph.

For "Joe Blogs was born in the city London" we have:

Joe Blogs \(\rightarrow^{was born in the city }\) London


\section{Method}
\label{sec:method}
% \nothing{In this section, we present our perception-guided neural scene synthesis for virtual reality. \zh{As a real-time overview: we first predict the the color as well as corresponding density for each pixel in the fovea, mid- and far- periphery (or designed 3D point?) given the camera position. Next we apply ray marching to generate the elemental image. Afterwards, we blend the results from each part and tune the contrast for each eye.}\qisun{merged with the following sentences. see if happy}}
Based on a concentric spherical representation and trained network predicting RGBDs on the spheres (\Cref{sec:method:representation}), our system predominantly comprises two main rendering steps in run-time: synthesizing visual-/stereoscopic-acuity-adaptive elemental images with ray marching for fovea, mid-, and far- peripheries; followed by image-based rendering to composite displayed frames (\Cref{sec:synthesis}).
For desired precision-performance balance, we further craft an analytical spatial-temporal model to optimize the determination of our intra-system variables, including representation sparsity and neural-network complexities (\Cref{sec:method:optimization}).
\input{TOG/fig_notations}
\subsection{Egocentric Neural Representation and Training}
\label{sec:method:representation}
The recent single-object-oriented ``outside-in'' view synthesis methods \cite{sitzmann2019deepvoxels,mildenhall2020nerf} typically represent the training targets using uniform voxelization. However, immersive VR environments introduce unique and open challenges for such parameterization due to the commonly egocentric (first-person) and ``inside-out'' viewing perspective (e.g., \Cref{fig:teaser:scene}).
As a consequence, the neural representation on large virtual environments typically suffer from ghosting artifacts, low resolution, or slow speed (\Cref{fig:teaser:quality}).
%We tailor our method specifically for egocentric (first-person) views in immersive VR environments.
%rendering of immersive viewer-centered ``inside-out'' scenes is challenging owing to the rapid variation of scene content.
\paragraph{Egocentric coordinate}
To tackle this problem, we are inspired by the recent panoramic imagery dis-occlusion methods \cite{Lin:DeepPanorama,Benjamin:2020:RTV,Broxton:immersiveLF}: we depict the rapidly varying first-person views with concentric spherical coordinates. This representation has been shown to allow for robust rendering at real-time rates and 6DoF interaction to navigate inside complex immersive environments.
As visualized in \Cref{fig:notations}, our representation is parameterized with the number of concentric spheres per neural network ($\sphereNum$) and their respective radii ($\mathbf{\sphereRadius}=\{\sphereRadius_i\},i\in [1,\sphereNum]$). \new{Under this spherical system, a given 3D spatial position can be represented as $\SpatialPt=\SpatialPt(\sphereRadius,\theta,\phi)$ where $\theta$ and $\phi$ are two angular numbers.
Similar to \cite{mildenhall2020nerf}, the run-time rendering goal is predicting a 4D vector $(r,g,b,d)$ for each $\SpatialPt$, followed by a view-dependent ray marching through this intermediate function to synthesize individual pixel.
}
Here, $(r,g,b)$ and $d$ are the color and density, respectively.
% \dnc{
% \paragraph{Network structure \textbf{*May need a name for our network?*}}
% Given a camera ray $(\rayo, \rayd)$, $\sphereNum$ points $\{\mathbf{\hat{\SpatialPt}}_i\}$ are sampled along it by calculating its intersections with $\sphereNum$ concentric spheres. Similar to NeRF\cite{mildenhall2020nerf}, we apply a trigonometric input encoding to every $\mathbf{\hat{\SpatialPt}_i}$ before feeding to a multi-layer perception (MLP). MLP is a network composed of $\mlpLayerNum$ fully-connected layers with $\mlpChannelNum$ channels in each layer. Then we integrate the predicted colors and densities through volume rendering method. The main differences between NeRF and our network are the input and output of the MLP component. NeRF takes every encoded coordinates as the input and outputs the corresponding color and density. This leads to extremely slow performance for view synthesis because network inference needs to be performed $\sphereNum$ times for each ray. To tackle this issue, we concatenate all $\sphereNum$ encoded coordinates to a vector and feed the coordinates to the MLP component so we only need to infer once for each ray. The output is the concatenated vector of colors and densities corresponding to input coordinates. As shown in \autoref{sec:result}, it is possible to achieve high-quality real-time egocentric and stereoscopic view synthesis through our network. \textbf{*May need some reason: why such a network structure works in our scenario?*}
% }

%\zh{ try rewriting a little bit.
\qisun{(May 15) double check and revise this paragraph, esp the beginning claims. I may want to add a small figure inset to explain the reasonale.}
\new{
\paragraph{Neural representation}
Existing neural rendering for ``outside-in'' viewing independently train neural networks to predict the 4D vector for individual $\SpatialPt$. This is due to the high variations in view points other than the viewing targets.
However, egocentric viewing is the opposite: despite the translation for 6DoF viewing, the observers' may change viewing targets frequently by rotating the head and gaze (See \Cref{fig:notations}).
That is, given a neural network's capability, a local egocentric neural representation may encode less viewing changes but more spatial variances.
To achieve this aim, we design the network to infer an array of vectors per viewing ray:
\begin{equation}
    \mlpFunc(\rayo, \rayd) \triangleq (\mathcal{R},\mathcal{G},\mathcal{B},\mathcal{D}).
    \label{eq:vector_rep}
\end{equation}
Here, $\rayo/\rayd$ defines a ray's origin/direction. $\mathcal{R},\mathcal{G},\mathcal{B},\mathcal{D}$ are $\sphereNum$ dimensional vectors representing the R/G/B/intensities of the $\sphereNum$ intersecting points ($\SpatialPt({\sphereRadius_i,\theta_i,\phi_i}), i\in[1,\sphereNum]$) between the ray and the concentric spheres. The system can then render individual color channels via integrating over $\mathcal{R}/\mathcal{G}/\mathcal{B}$ with $\mathcal{D}$ as weights.
%$\mlpFunc(\hat{\SpatialPt})\triangleq(r,g,b,d)$ of $\sphereNum$ intersection points $\mathbf{\hat{\SpatialPt}}({\sphereRadius_{i,i\in[1,\sphereNum]},\theta,\phi})$ between the ray and $\sphereNum$ spherical surfaces.
%Given a camera ray $(\rayo, \rayd)$, we calculated the intersection points between the ray $(\rayo, \rayd)$ and $\sphereNum$ concentric spheres. Thus, we have $\sphereNum$ points $\{\mathbf{\hat{\SpatialPt}}_i\}$ for each ray.
Denser spherical sampling (i.e., higher $\sphereNum$) lead to more precise quality but slower run-time performance.

Inspired by NeRF \cite{mildenhall2020nerf}, we devise a machine learning approach that encodes $\mlpFunc$ as a multi-layer perception (MLP) neural network.
NeRF predicts each individual intersection point $\{\mathbf{\hat{\SpatialPt}}_i\}$ before calculates the final color, causing slow performance due to the $\sphereNum$ network inference operation per ray in run-time.
Our egocentric-viewing-tailored representation (\Cref{eq:vector_rep}) concatenate all $\sphereNum$ encoded coordinates to a vector and feed the coordinates to the MLP module with only one inference.
During training, we define the input $\{\rayo, \rayd\}$ as the $\sphereNum$ intersecting points $\mathbf{\hat{\SpatialPt}_i}$. Our MLP module contains $\mlpLayerNum$ fully-connected layers with $\mlpChannelNum$ channels in each layer. %After, we employ a ray marching to calculate the color based on the predicted colors and densities of $\sphereNum$ points.
%As shown in \autoref{sec:result}, it is possible to achieve high-quality real-time egocentric and stereoscopic view synthesis through our network.
}

%\paragraph{Training and synthesis}
%For each scene, we approximate the function $\mlpFunc$ by a multilayer perceptron (MLP) network, similar to \cite{mildenhall2020nerf}. The network is composed of $\mlpLayerNum$ fully-connected layers of $\mlpChannelNum$ channels, each using ReLu as the activation function. We further determine $\mlpLayerNum$, $\mlpChannelNum$ and $\sphereNum$ via a spatial-temporal optimization in \Cref{sec:method:optimization}. Given rays of pixels in an image, the network predicts the colors and densities along these rays on every sphere. The ray marching weighted integrates predictions in back-to-front order to obtain actual colors of corresponding pixels. Similar to \cite{mildenhall2020nerf}, we apply a trigonometric input encoding and compute the L2-distance between the volume-rendered and mesh-rendered images as the training loss function. We discuss the specifics of training data creation and implementations in \Cref{sec:impl}.\nothing{\zh{Considering removing the last sentence. I think it is clear that this paragraph is not about details, guess reviewers are not expected to see the details. Or we should lead them not to expect details here.}}

\subsection{Gaze-Contingent Synthesis during Run-time}
\label{sec:synthesis}
%The scene representation above is created to parameterize a given 3D space for neural synthesis.
%the foveated rendering manner of VR display through training two orthogonal neural networks that are tailored for the perceptual acuity variances.
%\zh{shall we explicitly name the representation with exactly `concentric spherical coordinate system' earlier?}
Our concentric spherical coordinate, as described in \Cref{sec:method:representation}, addresses the large view target variance problem in the training stage.
However, it may still suffer from significant rendering latency (about half a second for each stereo frame). This is another essential challenges causing neural representation to be unsuitable yet for immersive viewing.
In this research, we leverage the spatially adaptive human visual- and stereoscopic- sensitivities to unlock fast runtime inference.
Instead of the typical single image prediction, we synthesize multiple elemental images to enable real-time responsiveness. The elemental images are generated based on the viewer's head and gaze motions and are adapted to the retinal acuity in resolution and stereo. %We detail our network design and elemental image synthesis in the following section. %We enable real-time responsiveness via introducing gaze-adaptive synthesis mechanisms.
\input{fig_system}
\subsubsection{Adaptive Monoscopic Acuity}
% The human vision is foveated. With the high field-of-view VR displays, we exploit the spatially-adaptive visual acuity to significantly accelerate the computation without compromising {\it perceptual} quality.
The human retinal ganglion cells, which collect and transmit visual information, are not uniformly distributed. Instead, its density in the visual fields close to the retinal center is much higher than the periphery \cite{watson2014formula}. This is referred as foveated vision with recent applications in accelerating immersive rendering \cite{Patney:2016:TFR,Kaplanyan:2019:DNR}.
Inspired by this, we significantly accelerate the runtime inference by integrating the characteristic of spatially-adaptive visual acuity without compromising the {\it perceptual} quality.

\new{Specifically, given device-tracked camera position ($\rayo$), direction ($\camDir$), and gaze position ($\gazeDir$), we synthesize three elemental images cover different eccentricity ranges of field-of-view (FoV) for each eye: the fovea ($\imageFoveal(\rayo,\camDir,\gazeDir)$, $0-20$ deg), the mid-eccentricity ($\imageMid(\rayo,\camDir,\gazeDir)$, $0-45$ deg) and the entire visual field ($\imageFar(\rayo,\camDir$), $0-110$ deg), as shown in \Cref{fig:system}. Note that $\imageFar$ is independent from the gaze direction $\gazeDir$.
% ZH: rewrite as a determined sentence.
Given the decreasing visual acuity from low to high eccentricities, we devise two orthogonal networks with different hyper parameters: $\mlpFunc_{foveal}$ for $\imageFoveal$ (the high acuity fovea), and $\mlpFunc_{periph}$ for $\imageMid$ and $\imageFar$ (reduced acuity).}
%\zh{Considering users have different perceptual sensitivities when the sizes of focus areas are different. We further trained two orthogonal networks with different hyper parameters. Eventually we trained $\mlpFunc_{foveal}$ for foveal image $\imageFoveal$ and $\mlpFunc_{periph}$ for mid-eccentricity image $\imageMid$ and high-eccentricity image $\imageFar$.}

To incorporate the display capabilities and aspect ratios, we define the resolutions of $\imageFoveal$/$\imageMid$/$\imageFar$ as \new{$256^2$/$256^2$/$230\times256$}.
That is, the $\imageFoveal$ has the highest spatial resolution of \new{$12.8$} pixels per degree (PPD), higher than those of $\imageMid$ ($5.7$ PPD) and $\imageFar$ ($2.33$ PPD).
%In each frame, the two networks independently return three elemental images, as seen from the separation range in deg, gradually larger areas along eccentricity. An example is shown in \Cref{fig:system}.
% ZH: add conclusive or ending sentences here.
%In each frame, the two networks independently return three elemental images, as seen from the separation range in deg, gradually larger areas along eccentricity. An example is shown in \Cref{fig:system}.
% ZH: add conclusion or ending sentences here.

\subsubsection{Adaptive Stereoscopic Acuity}
\qisun{(May 15) I feel like this section is a bit thin. Better idea on extending?}
Head-mounted VR displays require stereo rendering to provide parallax depth cues.
So do the elemental images $\imageFoveal^{\{l,r\}}$, $\imageMid^{\{l,r\}}$, and $\imageFar^{\{l,r\}}$ for each (\underline{$l$}eft and \underline{$r$}ight) eye.
The stereoscopic rendering, however, doubles the inference computation that is critical for latency- and frame-rate- sensitive VR experience
\nothing{The separation of the three elemental images considers the varied visual acuity. However, in a head-mounted stereo VR displays, the rendered image are for two eyes, resulting in double computation for $\imageFoveal^{\{l,r\}}$, $\imageMid^{\{l,r\}}$, and $\imageFar^{\{l,r\}}$. Here $l$ and $r$ represent the projection images for left ($\rayo^l$) and right ($\rayo^r$) eyes respectively.
Whereas, because $\imageMid^{\{l,r\}}$ and $\imageFar^{\{l,r\}}$ demand high spatial resolution due to their large eccentricity coverage, }
(please refer to \Cref{sec:study:intra} for breakdown comparisons).

We accommodate the inference process with the adaptive stereo acuity in perception.
In fact, besides the spatial visual acuity in monoscopic vision, psychophysical studies have also revealed human's significantly declined stereopsis while receding from the gaze point \cite{mochizuki2012magnitude}. Motivated by this characteristic, we perform the computation with $\imageFoveal^{\{l,r\}}$, $\imageMid^c$, and $\imageFar^c$ instead of inferring $6$ elemental images, where $c$ indicates the view at the central eye (the midpoint of the left and right eyes). \Cref{fig:mono} visualizes the stereopsis changes from the adaptation using an anaglyph.
\input{TOG/fig_mono_comparison}
\subsubsection{Real-time frame composition}%\dnc{May be moved to section 4 (merge with the paragraph 'Integration'). I think it's not closely related to our methodology and we have no key contributions about that. It's more like an engineering issue}\qisun{This whole section? I was concerned that would break the method completeness. Intentionally kept it short according to contribution level here.}
%\label{sec:method:blending}
%The individual elemental images are further blended as a single frame via a real-time image-based rendering.
\input{TOG/fig_blending}
With the obtained elemental images as input, an image-based rendering in the fragment shader is then executed to generate final frames for each eye (\Cref{fig:system:blending}).
%In real-time, we perform a image-based rendering that blends the elemental images.
The output frames are displayed on the stereo VR HMDs.
{
Two adjunct layers are blended using a smooth-step function across $40\%$ of the inner layer.
This enhances visual consistency on the edges between layers \cite{Guenter:2012:F3G}.
}
To accommodate the mono-view $\imageMid^c$ and $\imageFar^c$, they are shifted towards each eye according to approximated foveal depth range.
%\nothing{we shift it with $-/+ \frac{\rayo^r-\rayo^l}{2}$ for left/right eye respectively. }
Lastly, we enhance the contrast following the mechanism of \cite{Patney:2016:TFR} to further preserve peripheral elemental images' visual fidelity due to its low PDD. The details are visualized in \Cref{fig:method:blending}. %\dnc{Note: the contrast enhancement is performed on elemental images, before blending. Different enhancement parameters are applied for fovea, mid and periph layers}

\subsection{Latency-Quality Joint Optimization}
\label{sec:method:optimization}
As a view synthesis system based on sparse egocentric representation (the $\sphereNum$ spheres per network) and neural network synthesis (the $\mlpLayerNum, \mlpChannelNum$), neural rendering methods inevitably introduce approximation errors. \new{The errors can be reduced by introducing additional networks (thus lowered $\sphereNum$ assuming a fixed number of spheres representing a scene) and increasing individual network's capability (i.e., higher $\mlpLayerNum, \mlpChannelNum$). However,}
these variables also significantly increase the online computational time that is determined by inferring function $\mlpFunc$ and ray marching.
While VR strictly demanding both quality and performance, to seek the optimal latency-quality for human viewers, we present a spatial-temporal model that analytically depicts the correlations and optimizes the variables.

\paragraph{Precision loss of a 3D scene}
As shown in \Cref{fig:notations}, under the egocentric representation, a 3D point $\pt$ is re-projected as the nearest point on a sphere that connects it to the origin point:
\begin{equation}\label{eq:closestPoint3D}
{\pt^\prime}(\sphereNum,\mathbf{\sphereRadius},\SpatialPt) \triangleq \sphereRadius_k \frac{\pt}{\norm{\pt}}, \ k=\argmin_{j\in[1,\sphereNum]}\left(\norm{\norm{\SpatialPt}-\sphereRadius_j}\right).
\end{equation}

Similar to volume-based representation, the multi-spherical system is also defined in the discrete domain. The sparsity thus naturally introduces approximation error that compromises the synthesis quality. To analytically model the precision loss, we investigate the geometric relationship among the camera, the scene, and the representation.
As illustrated in \Cref{fig:teaser:scene,fig:notations},  for a sphere (located at origin point) with radius $\sphereRadius$, its intersection (if exists) with a directional ray $\{\rayo,\rayd\}$ is
\begin{equation}
\intersectionFunc(\sphereRadius,\rayo,\rayd) = \rayo + \left({\left((\rayo\cdot\rayd)^2-\norm{\rayo}^2+\sphereRadius^2\right)}^{\frac{1}{2}}-\rayo\cdot\rayd\right)\rayd,
\label{eq:raySphereIntersection}
\end{equation}
where $\rayo$ and $\rayd$ are the ray's origin point and normalized direction, respectively.
% \begin{equation}
% \left\{\intersectionFunc(\sphereRadius_i,\rayo,\rayd) \right\}\ |\ i\in[1,2,\dots,\sphereNum].
% \end{equation}
Inversely, given a view point $\rayo$ observing a spatial location $\SpatialPt$, the ray connecting them has the direction $\rayd(\SpatialPt,\rayo)=\frac{\SpatialPt-\rayo}{\norm{\SpatialPt-\rayo}}$. This ray may intersect with more than one sphere. Among them, the closest one to $\SpatialPt$ is:
\begin{equation}\label{eq:closestPointImg}
\begin{aligned}
    \hat{\pt}&(\rayo,\sphereNum, \mathbf{\sphereRadius},\SpatialPt) \triangleq \\
    &\intersectionFunc(\sphereRadius_k,\rayo,\rayd(\SpatialPt,\rayo))\ |\ k=\argmin_{j\in[1,\sphereNum]}\left(\norm{\norm{\SpatialPt}-\sphereRadius_j}\right).
\end{aligned}
\end{equation}
In the 3D space, the offset distance $\norm{\pt^\prime-\hat{\pt}}$ indicates the precision loss at $\pt$ from the representation. By integrating over all views and scene points, we obtain:
\begin{equation}
\begin{aligned}
\sparseError(\sphereNum, \mathbf{\sphereRadius})  &= \iint \norm{\pt^\prime(\sphereNum,\mathbf{\sphereRadius},\SpatialPt)-\hat{\pt}(\rayo,\sphereNum, \mathbf{\sphereRadius},\SpatialPt)} \mathbf{d}\SpatialPt \mathbf{d}\rayo,\\
&\forall \{\rayo, \SpatialPt\} \text{ pair without occlusion in between}.
\label{eq:sparseError}
\end{aligned}
\end{equation}
By integrating all 3D vertices $\SpatialPt$ and camera positions $\rayo$ in our dataset sampling, $\sparseError$ depicts how the generic representation precision of a scene, given a coordinate system defined by $\sphereNum$ and $\mathbf{\sphereRadius}$.

In comparison, a neural representation aims at predicting projected image given a $\rayo$ and $\camDir$. Thus, we further extend \Cref{eq:sparseError} to image space to analyze the error given a set of camera's projection matrix  $\projectionMatrix(\rayo,\camDir)$ as
%However, typical 3D representations are not uniformly distributed points. Moreover, the network only predicts pixel colors/intensities but not depth. By extending \Cref{eq:sparseError} to the captured image space data, we obtain
\begin{align}
\imgSpaceError(\sphereNum, \mathbf{\sphereRadius}, \rayo, \camDir)  = \int \norm{\projectionMatrix(\rayo,\camDir)\cdot\left(\SpatialPt-
\hat{\pt}(\rayo,\sphereNum, \mathbf{\sphereRadius},\SpatialPt)\right)}\mathbf{d}\SpatialPt.
\label{eq:imageError}
\end{align}
From \Cref{fig:notations,eq:imageError}, we observe:
given a fixed min/max range of $\mathbf{\sphereRadius}$, $\sphereNum$ is negatively correlated to $\imgSpaceError$;
with a fixed $\sphereNum$, the correlation between distribution of $\sphereRadius_j$ and scene content (i.e., distribution of $\SpatialPt$s) also determines $\imgSpaceError$.

However, for neural scene representation, infinitely increasing network capabilities may significantly raise the challenges in training precision and inference performance.
Likewise, increasing representation densities (i.e., lower $\sphereNum$) and/or network complexities (i.e., higher $\mlpLayerNum$/$\mlpChannelNum$) naturally improves the image output quality (lower \Cref{eq:imageError}). However, this significantly increases the computation during ray marching, causing quality drop stretched along time. In the performance-sensitive VR scenario, the latency breaks the continuous viewing experiment and may cause simulator sickness. Thus, with content-aware optimization, we further optimize the system towards an ideal quality-speed balance.%\zh{did not specify coordinate variables before. As well as consistent with the following ``optimal coordinate system ($\sphereNum$ and $\mathbf{\sphereRadius}$) and MLP settings ($\mlpLayerNum$/$\mlpChannelNum$)''}

\paragraph{Spatial-temporal modeling}
\input{TOG/fig_optimization}
Inspired by \cite{Li:2020:TSP,albert2017latency}, we perform spatial-temporal joint modeling to determine the optimal coordinate system ($\sphereNum$) for positional precision and network complexity ($\mlpLayerNum$, $\mlpChannelNum$) for color precision that adapt to individual computational resources and scene content. This is achieved via latency-precision modeling in the spatial-temporal domain:
%Specifically, we model the prediction image $P$ with gaze position ($G$) at time $t$ as $P_G(t)$ and the ground truth retinal image (from a simulated local rendering) as $\hat{P}_G(t)$.
%In practice, increasing the number of spheres $\sphereNum$ or number of MLP layers may affect the computational and transmissional latency but will improve the quality of individual frames (as in \Cref{eq:imageError}). Thus, we define the perceptual error as:
\begin{equation}
\begin{aligned}
\finalError(\sphereNum, &\mlpLayerNum, \mlpChannelNum) =
\sum_t\int \mlpFunc_{\mlpLayerNum, \mlpChannelNum}(\SpatialPt)\times\\ &\norm{\projectionMatrix(\rayo_t,\camDir_t)\cdot\SpatialPt-\projectionMatrix(\rayo_{t-\latency},\camDir_{t-\latency})\cdot\pt(\sphereRadius_k,\rayo_{t-\latency},\rayd_{t-\latency})}\mathbf{d}\SpatialPt,
%&\int  \norm{ \imgSpaceError(\sphereNum, \mathbf{\sphereRadius}, \rayo_t, \rayd_t) - \imgSpaceError(\sphereNum, \mathbf{\sphereRadius}, \rayo_{t-l(\sphereNum, \mathbf{\sphereRadius})}, \rayd_{t-l(\sphereNum, \mathbf{\sphereRadius})})) } \mathbf{d} t
\label{eq:error:image}
\end{aligned}
\end{equation}
where $\latency\triangleq\latency(\sphereNum, \mlpLayerNum, \mlpChannelNum)$ is the system latency with a given coordinate and network setting.
$\mlpFunc_{\mlpLayerNum, \mlpChannelNum}(\SpatialPt)$ is the four ($r,g,b,a$) output channels' L1-distance between a given network setting and the highest values $\sphereNum=8,\mlpLayerNum=4,\mlpChannelNum=1024$). For simplicity, we assumed uniformly distributed $\mathbf{\sphereRadius}$ with a fixed range of the spherical coverage.%\zh{``and0 the highest values'' ??}

As suggested by Albert et al. \shortcite{albert2017latency}, the latency for a foveated system shall reach below \textasciitilde$50$ms for undetectable artifacts. Given our test device's eye-tracking latency \textasciitilde$12ms$ and the photon submission latency \textasciitilde$14ms$ (\cite{albert2017latency}), the synthesis and rendering latency shall be less than $L_0 = 24$ms.
Thus, we determine the optimal $\{\sphereNum, \mathbf{\sphereRadius}\}$ to balance latency and precision as
\begin{equation}
\begin{aligned}
    &\argmin_{\sphereNum, \mlpLayerNum, \mlpChannelNum} \finalError(\sphereNum, \mlpLayerNum, \mlpChannelNum), \\
    & s.t.\ {l(\sphereNum, \mathbf{\sphereRadius})} < L_0.
\end{aligned}
\end{equation}
\Cref{fig:optimization} visualizes an example of the optimization mechanism for an foveal image $\imageFoveal$. The optimized results ($\sphereNum, \mlpLayerNum, \mlpChannelNum$) for individual networks are used for training. The optimization outcomes are detailed in \Cref{sec:impl}.
The visual quality is validated by psychophysical study (\Cref{sec:study:user}) and objective analysis (\Cref{sec:study:quality}). The latency breakdown of our system is reported in \Cref{sec:study:intra}.


\section{Results}
\label{sec:results}
Among the exhaustive amount of tests conducted with most of the possible combinations of tweet representation and classification methodologies, we will present the results that helped us to better understand each algorithm.

First, Word embeddings were experimented with all four different options, \textit{baseline}, \textit{trained}, \textit{pretrained} and \textit{merged} as they are described in Section~\ref{sec:tweetRepresentations}.
In order to understand the performance of SVM classifier in this configuration, we also tested NN classifier for the same data representations.
For this purpose, we first intended to find the best possible NN configuration for the resources we have, since more powerful architectures require more computational and memory resources.
Both single hidden layer and two hidden layers architectures with different number of neurons are trained.
Table \ref{table:nn} gives the architectures and corresponding abbreviations, which are used in Figure \ref{fig:perf1} to give a clear picture of performances for different GloVe embeddings and SVM-NN classifiers.

\input{table1}

\begin{figure}[t]
	\centering
	\includegraphics[width=0.8\columnwidth]{glove_NN_SVM.png}
	\caption{Performance of SVM/NN classifiers using GloVe representations obtained by a variety of dictionaries}
	\label{fig:perf1}
\end{figure}

As can be seen from the performance chart, NN outperformed SVM for all cases.
In addition, the best performance is obtained with the largest single layer NN architecture, i.e. NN3, which was the biggest that our resources enabled us.
Second hidden layer, i.e., more nonlinearity never achieved better.
Regarding the \textit{GloVe} dictionaries, pre-trained vocabulary always lead to better results compared to trained ones, which is expected due to the amount of data used for the pre-trained vocabulary.
However, merging the new words contributes to performance by $1\%$ for both NN an SVM classifiers.
Only interesting thing to notice is the fact that utilization of TF-IDF constants as weighting coefficients for \textit{GloVe} representations does not improve the classification performance.
In fact, we obtained $81.50\%$ classification accuracy with weighted representations of \textit{pretrained} vocabulary and NN3 classifier, whereas the raw representations achieved $82.14\%$.

Furthermore, we investigated the performance of \textit{n-grams} representation for different window sizes, where it is applied to preprocessed tweets and SVM is utilized as the classifier.
Results are summarized in Figure \ref{fig:perf_ngrams}
with 4-grams to seem to be the best representation.

\begin{figure}[h!]
	\centering
	\begin{subfigure}{0.48\columnwidth}
		\centering
		\includegraphics[width=\linewidth]{ngrams.png}
		\caption{n-grams: Performance vs. \textit{n}}
		\label{fig:perf_ngrams}
	\end{subfigure}
	\begin{subfigure}{0.48\columnwidth}
		\centering
		\includegraphics[width=\linewidth]{fasttext.png}
		\caption{FastText: Performance vs. \textit{D}}
		\label{fig:perf_ft}
	\end{subfigure}
\end{figure}

As another test, FastText algorithm is experimented for different dimensions of representations, results of which is given in Figure \ref{fig:perf_ft}.
For all different dimensions, preprocessed dataset is utilized and the classifier is trained with a learning rate $0.05$ by 50 epochs.
Dimension of $200$ seems to give the best accuracy.

In order to further observe the contribution of preprocessing step, we also chose the best-performing n-gram and FastText configurations to apply them to raw data.
results presented in Table \ref{table:preprocess} clearly indicates that proposed preprocessing step adds around $2\%$ to the classification performance.

\input{table2}

The last but not the least, we trained several CNN architectures, where we altered the capacity of the network in order see the limits of the algorithm regarding the training data.
Best performance is achieved when we use a single hidden layer with 128 neurons, where 128 convolutional filters of \{2,3,4,5,6\} neighborhoods are used.
Regarding the computational necessities, instead of cross-validation, we kept randomly chosen 10K samples of training dataset for the validation for all training attempts.
Figure \ref{fig:cnn_train} illustrates the evolution of accuracy during the training.
Roughly speaking, after 18K steps, we suspected model to overfit due to the divergence of accuracy values for training and validation dataset, but as can be seen on the second figure, when we kept training with another randomly chosen validation data due to non-constant seeds, validation performance was better than the training.
The main reason behind this difference is related to the fact that second validation set had been used for the training at the first stage.
Since we didn't have enough time for a training from scratch, we stopped the training at around 30K global steps, which gave us $87.54\%$ test error, which had been $87.48\%$ after 18K global steps.

\begin{figure}[h!]
	\centering
	\begin{subfigure}{\columnwidth}
		\centering
		\includegraphics[width=\linewidth]{accuracy1.png}
		\caption{}
		\label{fig:18k}
	\end{subfigure}
	\begin{subfigure}{\columnwidth}
		\centering
		\includegraphics[width=\linewidth]{accuracy2.png}
		\caption{}
		\label{fig:30k}
	\end{subfigure}
	\caption{Evolution of accuracy values for training(orange, smoothed) and validation(blue) datasets for \ref{fig:18k} first 18K steps and \ref{fig:30k} remaining 12K steps}
	\label{fig:cnn_train}
\end{figure}

When we increased or decreased the capacity of networks by increasing/decreasing the number of filters per neighborhood sizes as well as the number neighborhoods, or adding another hidden layer before soft-max classifier, performance always got worse.
If we increased the capacity, decay in the performance is related to overfitting and if we decrease the capacity, deterioration can be due to insufficient representational power.


\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage{amsmath,amssymb,amsthm,amsfonts}
\usepackage{mathtools}
\usepackage{hyperref}
\usepackage{authblk}

\newcommand{\G}{\mathbb{G}}
\newcommand{\F}{\mathbb{F}}
\newcommand{\func}[1]{\mathsf{#1}}
\newcommand{\addr}{\func{addr}}
\newcommand{\comm}{\func{Comm}}
\newcommand{\hash}{\mathcal{H}}

\title{Spats: user-defined confidential assets for the Spark transaction protocol}
\author[1]{Aaron Feickert}
\author[2,3]{Aram Jivanyan\thanks{Corresponding author: \texttt{aram@firo.org}}}
\affil[1]{Cypher Stack}
\affil[2]{Firo}
\affil[3]{Yerevan State University}
\date{\today}

\begin{document}

\maketitle

In privacy-preserving transaction protocols, confidential asset designs permit transfer of quantities of distinct asset types in a way that obscures their types and values.
Spark is a protocol that provides flexible privacy properties relating to addressing, transaction sources and recipients, and value transfer; however, it does not natively support the use of multiple confidential asset types.
Here we describe Spats, a new design for confidential assets compatible with Spark that focuses on efficient and modular implementation.
It does so by extending coin value commitments to bind and mask an asset type, and asserting in zero knowledge that this type is maintained throughout transactions.
We describe the cryptographic components and changes to the Spark protocol necessary for the design of Spats.

\section{Introduction}

Privacy-preserving transaction protocols have seen a wealth of research.
Protocols like RingCT \cite{ringct} in Monero, Sprout and Sapling \cite{zcash_sprout, zcash_sapling, zcash} in Zcash, Mimblewimble \cite{mw} in Grin and Beam, and Lelantus \cite{lelantus} in Firo each take different approaches toward privacy.
These protocols may provide useful functionality relating to transaction graph ambiguity or obfuscation, addressing, amount confidentiality, and scaling.

Spark \cite{spark} is a recent protocol, based on techniques from Lelantus, that provides trustless and flexible confidential transactions.
In Spark, coins of hidden and arbitrary value can be transferred in a manner that uses zero-knowledge proofs to hide amounts and provide ambiguity as to the coins consumed in a transaction, while using a non-interactive ephemeral approach to dissociate recipient addresses from coins directed to them.

However, Spark, like many other privacy-focused protocols, is limited to the transfer of a single asset type.
The concept of confidential assets refers to protocol designs that permit the maintenance of distinct pools of value that can be transferred in a manner hiding the amounts and types of assets involved in transactions.

Early work in this area was conducted by Poelstra and collaborators \cite{poelstra}, with the Bitcoin and Mimblewimble designs in mind.
This approach to confidential assets uses Pedersen commitments with asset-specific generators to produce transactions where the types, amounts, and distributions of transferred assets are hidden; however, the transaction graph itself is only obscured up to the practical limits imposed by the overlying protocols.
Further, this relative lack of information leakage comes at a cost: commitment range proofs cannot be aggregated to save space, and each generated coin must come equipped with a proof that it corresponds to a valid asset type.

Later work by Beam \cite{lelantus_cla} extends the Lelantus protocol by applying Poelstra \textit{et al.}'s construction to take advantage of transaction graph obfuscation.
In this design, the identity of consumed coins is hidden by re-randomized commitments, and one-of-many asset validity proofs use a design by Groth and Kohlweiss \cite{groth} (later optimized by Bootle and collaborators \cite{bootle}) with improved scaling.

In this paper, we propose Spats, a new design for confidential assets that offers different tradeoffs in efficiency and information leakage.
Unlike earlier work that relies on asset-specific commitment generators to separate assets for balance integrity, Spats coins bind to asset types using an extended commitment with fixed global generators.
This design choice permits range proof aggregation; when used with range proof constructions like Bulletproofs \cite{bp} or Bulletproofs+ \cite{bp_plus} that scale logarithmically with the number of commitment assertions, the space savings can be impressive.
Further, by restricting each transaction to a single hidden asset type in addition to a base asset used for fee handling, we replace multiple asset validity proofs with a single fixed-size asset type equality proof that applies to all consumed and generated coins of the hidden type.

We note carefully that a modification of the full protocol security model of \cite{spark} accounting for our changes, while important, is deferred to future work.

\section{Primitives}

We describe the cryptographic constructions required for the Spats protocol.
Throughout this paper, let $\G$ be a prime-order group where the discrete logarithm, computational Diffie-Hellman, and decisional Diffie-Hellman problems are hard, and let $\F$ be its scalar field.

\subsection{Extended commitments}

The constructions used in Spats, like some of those used in the original Spark protocol, use homomorphic commitments with two independent value components; for clarity, we refer to these as \textit{extended commitments}.
Such a commitment scheme is common, and is often used more generally to bind to and hide a vector of values with a single mask.
The public parameters are $pp_{\text{com}} = (\G, \F, F, G, H)$, where $F, G, H \in \G$ are independent public generators; that is, they have no efficiently-computable discrete logarithm relationship.
The commitment scheme consists of a function $\func{Comm}: \F^3 \to \G$ that is additively homomorphic.
For our purposes, we let $\func{Comm}$ be a Pedersen commitment, where $$\func{Comm}(v, v', m) = vF + v'G + mH$$ for all values $v, v' \in \F$ and masks $m \in \F$.

\subsection{Parallel one-of-many proving system}

The parallel one-of-many proving system definition used in Spark is modified to support extended commitments.
The public parameters are $pp_{\text{par}} = (n, m, pp_{\text{comm}})$, where $pp_{\text{com}}$ are the public parameters for an extended commitment construction.
The algorithm tuple $(\func{ParallelProve}, \func{ParallelVerify})$ is modified to support the following relation:
\begin{multline*}
\left\{ pp_{\text{par}}, \{S_k,V_k\}_{k=0}^{N-1} \subset \G^2, S',V' \in \G ; l \in \mathbb{N}, (s,v) \in \F : \right. \\
\left. 0 \leq l < N, S_l - S' = \comm(0,0,s), V_l - V' = \comm(0,0,v) \right\}
\end{multline*}

The existing parallel one-of-many proving system in the Spark protocol is trivially modified to support this definition, since it also reduces to an assertion of commitments to zero.

\subsection{Range proving system}

The range proving construction is modified to support extended commitments.
The public parameters are $pp_{\text{rp}} = (v_{\text{max}}, pp_{\text{comm}})$, where $pp_{\text{comm}}$ are the public parameters for an extended commitment construction.
The algorithm tuple $(\func{RangeProve}, \func{RangeVerify})$ is modified to support the following relation:
\begin{multline*}
\{ pp_{\text{rp}}, \{C_j\}_{j=1}^m \in \G ; \{(a_j, v_j, r_j)\}_{j=1}^m \in \F : \\
\forall j \in [1,m], 0 \leq v_j < v_{\text{max}}, C_j = \comm(a_j, v_j, r_j) \}
\end{multline*}

We describe here a modification to the Bulletproofs+ range proving system to support this construction.
Zarcanum \cite{zarcanum} provides a security proof for such a proving system.
Note that we use additive notation to describe these changes, in order to match this convention in the Spark protocol, and we describe here only those aspects of the prover and verifier algorithms that are modified from those in \cite{bp_plus}.

The prover selects a value $\underline{\alpha} \in \F$ uniformly at random.
It constructs $$A = \vec{a}_L \vec{G} + \vec{a}_R \vec{H} + \comm(\underline{\alpha}, 0, \alpha)$$ and defines $$\widehat{\underline{\alpha}} = \underline{\alpha} + \sum_{j=1}^m z^{2j}a_j y^{mn+1}$$ as an additional witness to the weighted inner-product argument protocol we describe now.

The zero-knowledge weighted inner-product protocol is modified to support the following relation:
\begin{multline*}
\{ pp_{\text{erp}}, \vec{G}, \vec{H} \in \G^n, P \in \G; (\vec{a}, \vec{b}) \in \F^n, (\alpha, \underline{\alpha}) \in \F : \\
P = \vec{a}\vec{G} + \vec{b}\vec{H} + \comm(\underline{\alpha}, \vec{a} \odot_y \vec{b}, \alpha) \}
\end{multline*}

In the case $n > 1$, the prover selects $\underline{d}_L, \underline{d}_R \in \F$ uniformly at random.
It computes
\begin{align*}
    L &= (y^{-\widehat{n}}\vec{a}_1)\vec{G}_2 + \vec{b}_2 \vec{H}_1 + \comm(\underline{d}_L, c_L, d_L) \\
    R &= (y^{\widehat{n}}\vec{a}_2)\vec{G}_1 + \vec{b}_1 \vec{H}_2 + \comm(\underline{d}_R, c_R, d_R)
\end{align*}
and $\widehat{\underline{\alpha}} = \underline{d}_L e^2 + \underline{\alpha} + \underline{d}_R e^{-2}$.

In the case $n = 1$, the prover selects $\underline{\delta}, \underline{\eta} \in \F$ uniformly at random.
It computes
\begin{align*}
    A &= r\vec{G} + s\vec{H} + \comm(\underline{\delta}, r \odot_y \vec{b} + s \odot_y \vec{a}, \delta) \\
    B &= \comm(\underline{\eta}, r \odot_y s, \eta)
\end{align*}
and $\underline{\delta}' = \underline{\eta} + \underline{\delta} e + \underline{\alpha} e^2$.
It sends $\underline{\delta}'$ to the verifier.

The verifier accepts if and only if the following holds:
$$e^2 P + eA + B = (r'e)\vec{G} + (s'e)\vec{H} + \comm(\underline{\delta}', r' \odot_y s', \delta')$$

Observe that this construction adds only $\underline{\delta}'$ to the overall proof structure.

\subsection{Aggregated representation proof}

We require a proving system to assert in zero knowledge that the prover knows discrete logarithm representations of a set of extended commitments with a zero component.
In the context of Spats, this is used to show that certain extended commitments reduce to standard commitments by setting one component's discrete logarithm to zero, and is useful by allowing optimal aggregation of commitment range proofs for space efficiency.
Let $pp_{\text{agg}} = (pp_{\text{comm}})$ be the public parameters of such a proving system, where $pp_{\text{comm}}$ are the public parameters for an extended commitment construction.

The proving system is a tuple of algorithms $(\func{AggProve}, \func{AggVerify})$ for the following relation:
$$\{ pp_{\text{agg}}, \{C_i\}_{i=0}^{n-1} ; (\{y_i, z_i\}_{i=0}^{n-1}) : \forall i \in [0,n), C_i = \comm(0, y_i, z_i) \}$$

The batch Schnorr proving system described in \cite{batch_schnorr} may be easily generalized for this purpose, since an extended commitment with a zero component is algebraically equivalent to a standard Pedersen commitment.

\subsection{Asset type equality proof}

We introduce a new proving system to prove in zero knowledge that a set of extended commitments share a common single discrete logarithm in one component.
In the context of Spats, this proving system will be used to assert in zero knowledge that coins consumed and generated in a transaction share a common asset type.
Let $$pp_{\text{type}} = (pp_{\text{comm}})$$ be the public parameters of such a proving system, where $pp_{\text{comm}}$ are the public parameters for an extended commitment construction.

The proving system is a tuple of algorithms $(\func{TypeProve}, \func{TypeVerify})$ for the following relation:
$$\{ pp_{\text{type}}, \{C_i\}_{i=0}^{n-1} \in \G ; (x, \{y_i, z_i\}_{i=0}^{n-1}) \in \F : \forall i \in [0,n), C_i = \comm(x, y_i, z_i) \}$$

The protocol proceeds as follows:
\begin{enumerate}
    \item The prover selects $r_x, r_y, r_z, s_y, s_z \in \F$ uniformly at random.
    \item The prover computes $A = \comm(r_x, r_y, r_z)$ and $B = \comm(0, s_y, s_z)$, and sends these values to the verifier.
    \item The verifier selects $c \in \F$ uniformly at random, and sends this challenge value to the prover.
    \item The prover computes the values
    \begin{align*}
        t_x &= r_x + cx \\
        t_y &= r_y + cy_0 \\
        t_z &= r_z + cz_0 \\
        u_y &= s_y + \sum_{i=1}^{n-1} c^i(y_i - y_0) \\
        u_z &= s_z + \sum_{i=1}^{n-1} c^i(z_i - z_0)
    \end{align*}
    and sends them to the verifier.
    \item The verifier accepts the proof if and only if the following hold:
    \begin{align}
        \comm(t_x, t_y, t_z) &= A + cC_0 \label{eqn:type-1} \\
        \comm(0, u_y, u_z) &= B + \sum_{i=1}^{n-1} c^i(C_i - C_0) \label{eqn:type-2}
    \end{align}
\end{enumerate}

We now prove that this construction is a sigma protocol for the given relation.

\begin{proof}
To show the construction is a sigma protocol, we must show that it is complete, special sound, and honest-verifier zero knowledge.

Completeness follows trivially by inspection.

We now show that the protocol is $n$-special sound by constructing an extractor that produces a witness set on $n$ accepting transcripts with distinct challenges.
Consider $n$ distinct challenges $\{c_j\}_{j=0}^{n-1}$ corresponding to response transcripts $\{(t_x^j, t_y^j, t_z^j, u_y^j, u_z^j)\}_{j=0}^{n-1}$, respectively, where we use superscript indexing.
By applying Equation \ref{eqn:type-1} to the $j = 0$ and $j = 1$ transcripts and subtracting them, we obtain the following:
$$\comm(t_x^1 - t_x^0, t_y^1 - t_y^0, t_z^1 - t_z^0) = (c_1 - c_0)C_0$$
Since $c_1 \neq c_0$ by assumption, we have the following extracted witnesses:
\begin{align*}
    x &= \frac{t_x^1 - t_x^0}{c_1 - c_0} \\
    y_0 &= \frac{t_y^1 - t_y^0}{c_1 - c_0} \\
    z_0 &= \frac{t_z^1 - t_z^0}{c_1 - c_0}
\end{align*}

To extract the remaining witness elements, apply Equation \ref{eqn:type-2} to obtain the following system of equations:
\begin{gather}
\begin{aligned}
    \label{eqn:sound}
    B + \sum_{i=1}^{n-1} c_0^i(C_i - C_0) &= \comm(0, u_y^0, u_z^0) \\
    B + \sum_{i=1}^{n-1} c_1^i(C_i - C_0) &= \comm(0, u_y^1, u_z^1) \\
    &\vdotswithin{=} \\
    B + \sum_{i=1}^{n-1} c_{n-1}^i(C_i - C_0) &= \comm(0, u_y^{n-1}, u_z^{n-1})
\end{aligned}
\end{gather}
Subtract each equation from the first:
\begin{align*}
    \sum_{i=1}^{n-1} (c_1^i - c_0^i)(C_i - C_0) &= \comm(0, u_y^1 - u_y^0, u_z^1 - u_z^0) \\
    \sum_{i=1}^{n-1} (c_2^i - c_0^i)(C_i - C_0) &= \comm(0, u_y^2 - u_y^0, u_z^2 - u_z^0) \\
    &\vdotswithin{=} \\
    \sum_{i=1}^{n-1} (c_{n-1}^i - c_0^i)(C_i - C_0) &= \comm(0, u_y^{n-1} - u_y^0, u_z^{n-1} - u_z^0)
\end{align*}
Then we define a set $\{y_i\}_{i=1}^{n-1}$ via the following linear system:
\begin{align*}
    \sum_{i=1}^{n-1} (c_1^i - c_0^i)(y_i - y_0) &= u_y^1 - u_y^0 \\
    \sum_{i=1}^{n-1} (c_2^i - c_0^i)(y_i - y_0) &= u_y^2 - u_y^0 \\
    &\vdotswithin{=} \\
    \sum_{i=1}^{n-1} (c_{n-1}^i - c_0^i)(y_i - y_0) &= u_y^{n-1} - u_y^0
\end{align*}
Since the challenges are uniformly distributed, the system has a unique solution in $\{y_i\}_{i=1}^{n-1}$ with high probability.
We can form a similar linear system to obtain unique $\{z_i\}_{i=1}^{n-1}$.

This implies that the terms $C_i - C_0 = \comm(0, y_i - y_0, z_i - z_0)$ satisfy the original linear system in Equation \ref{eqn:sound} for all $i \in [1,n)$.
From our earlier extraction we have $C_0 = \comm(x, y_i, z_i)$, so for $i \in [1,n)$ we have $C_i = \comm(x, y_i, z_i)$ as required.

It remains to show that these solutions are unique; that is, that no $C_i$ has a different representation with coefficients $x',y_i',z_i'$ consistent with successful verification.
If this were the case, then we must have the polynomial equation $\sum_{i=0}^{n-1} c^i(y_i - y_i') = 0$ in $c$; however, since $c$ is selected randomly by the verifier, all coefficients of the polynomial must (with overwhelming probability) be zero by the Schwartz-Zippel lemma.
Hence each $y_i = y_i'$ (and by the same reasoning, $z_i = z_i'$ and $x = x'$), and the extracted witness set is unique.

It remains to prove that the protocol is honest-verifier zero knowledge.
To show this, we construct a simulator that produces transcripts distributed identically to those of valid proofs.
Given a valid statement and random challenge $c \in \F$, the simulator chooses $t_x, t_y, t_z \in \F$ uniformly at random, and sets $A = \comm(t_x, t_y, t_z) - cC_0$ using these values.
It selects $u_y, u_z \in \F$ uniformly at random, and sets
$$B = \comm(0, u_y, u_z) - \sum_{i=1}^{n-1} c^i(C_i - C_0)$$
using these values.
By construction, this transcript passes the verification Equations \ref{eqn:type-1} and \ref{eqn:type-2}.
Since the extended commitment generators are independent, all proof elements in both the simulation and real proofs are identically uniformly distributed.

This completes the proof.
\end{proof}

\subsection{Balance proof}

We require a representation proof for use in balance assertion.
It proves that a extended commitment is bound to a zero value.
In the context of Spats, this proving system will be used to assert that value is maintained between consumed and generated coins in a transaction.
Let $$pp_{\text{bal}} = ( pp_{\text{comm}})$$ be the public parameters of such a proving system, where $pp_{\text{comm}}$ are the public parameters for an extended commitment construction.

The proving system is a tuple of algorithms $(\func{BalanceProve}, \func{BalanceVerify})$ for the following relation:
$$\{ pp_{\text{bal}}, C \in \G ; (x, z) \in \F : C = \comm(x, 0, z) \}$$

The protocol proceeds as follows:
\begin{enumerate}
    \item The prover selects $r_x, r_z \in \F$ uniformly at random.
    \item The prover computes $A = \comm(r_x, 0, r_z)$ and sends this value to the verifier.
    \item The verifier selects $c \in \F$ uniformly at random, and sends this challenge value to the prover.
    \item The prover computes the values
    \begin{align*}
        t_x &= r_x + cx \\
        t_z &= r_z + cz
    \end{align*}
    and sends them to the verifier.
    \item The verifier accepts the proof if and only if $\comm(t_x, 0, t_z) = A + cC$ holds.
\end{enumerate}
This construction is a sigma protocol for the given relation; the proof is standard, and we omit it here.

\section{Protocol}

We now describe the changes to the Spark protocol algorithms required for Spats.
We assume the use of notation from \cite{spark}.
Note that key creation, address creation, and coin recovery are unchanged, so we do not repeat those algorithms here.

In the Spats construction, an asset type is defined as a scalar $a \in \F$; all coins associated to a given asset type must share a common $a$.
The intent is that asset types, like coin values, are bound to coins in a hidden manner and made public only when introducing new value into the system.
Consensus rules must determine the conditions under which new value for any asset type may be added.

As a matter of terminology and notational convenience, if a coin has asset type $a = 0$, we call it a \textit{base asset} coin; otherwise, we call it a \textit{generic asset} coin.

\subsection{\texorpdfstring{$\func{CreateCoin}$}{CreateCoin}}

This algorithm generates a new coin of arbitrary asset type destined for a given public address.
It uses a type bit to determine if the value and asset type are intended to be publicly visible.

\textbf{Inputs:} Destination public address $\addr_{\text{pk}}$, value $v \in [0, v_{\text{max}})$, memo $m$, asset type $a \in \F$, type bit $b$

\textbf{Outputs:} Coin $\func{Coin}$, nonce $k$

\begin{enumerate}
\item Parse the recipient address $\addr_{\text{pk}} = (d, Q_1, Q_2)$.
\item Sample a nonce $k \in \F$.
\item Compute the recovery key $K = \hash_k(k)\hash_{\text{div}}(d)$.
\item Compute the serial number commitment $$S = \comm(\hash_{\text{ser}}(k), 0, 0) + Q_2.$$
\item Generate the value commitment $C = \comm(a, v, \hash_{\text{val}}(k))$.
\item If $b = 0$, set the recipient data $r = (v,a,d,k,m)$; otherwise, set $r = (d,k,m)$.
\item Generate an AEAD encryption key $k_{\text{aead}} = \func{AEADKeyGen}(\hash_k(k)Q_1)$; encrypt the recipient data $$\overline{r} = \func{AEADEncrypt}(k_{\text{aead}},\texttt{r},r).$$
\item If $b=0$, output the coin $\func{Coin} = (S, K, C, \overline{r})$ and nonce $k$; otherwise, output the coin $\func{Coin} = (S, K, C, v, a, \overline{r})$ and nonce $k$.
\end{enumerate}
The case $b=0$ represents a coin with hidden value being generated in a spend transaction, while the case $b=1$ represents a coin with plaintext value being generated in a mint transaction.

\subsection{\texorpdfstring{$\func{Mint}$}{Mint}}

This algorithm generates new coins of arbitrary asset type from either a mining-type process defined by consensus rules, or by consuming non-Spark outputs from a base layer with public value.
Note that while such implementation-specific auxiliary data may be necessary for generating such a transaction and included, we do not specifically list this here.

\textbf{Inputs}: Set of $t$ output coin public addresses, values, memos, and asset types: $$\{\addr_{\text{pk},j}, v_j, m_j, a_j\}_{j=0}^{t-1}$$

\textbf{Outputs}: Mint transaction $\text{tx}_{\text{mint}}$

\begin{enumerate}
    \item Generate a set $\func{OutCoins} = \{\func{CreateCoin}(\addr_{\text{pk},j}, v_j, m_j, a_j, 1)\}_{j=0}^{t-1}$ of output coins.
    \item Parse the output coin value commitments $\{\overline{C}_j\}_{j=0}^{t-1}$ from $\func{OutCoins}$, where each $\overline{C}_j$ contains nonce $k_j$.
    \item Generate a representation proof for value assertion: $$\Pi_{\text{val}} = \func{RepProve}\left( pp_{\text{rep}}, H, \{ \overline{C}_j - \comm(a_j, v_j, 0) \}_{j=0}^{t-1}; \{\hash_{\text{val}}(k_j)\}_{j=0}^{t-1} \right)$$
    \item Output the mint transaction $\func{tx}_{\text{mint}} = (\func{OutCoins}, \Pi_{\text{val}})$.
\end{enumerate}

\subsection{\texorpdfstring{$\func{Identify}$}{Identify}}

This algorithm allows a recipient (or designated entity) to determine if it controls a coin; if so, it computes the value, memo, and diversifier from the coin (in addition to the coin nonce).
It requires the incoming view key used to produce diversified addresses to do so.
If the coin is not destined for any diversified address, the algorithm returns failure.

It is assumed that the recipient has run the $\func{Verify}$ algorithm on the transaction generating the coin being identified.

\textbf{Inputs:} Incoming view key $\addr_{\text{in}}$, coin $\func{Coin}$

\textbf{Outputs:} Value $v$, memo $m$, asset type $a$, diversifier $i$, nonce $k$

\begin{enumerate}
\item Parse the incoming view key $\addr_{\text{in}} = (s_1, P_2)$.
\item If $\func{Coin}$ was generated in a mint transaction, parse $\func{Coin} = (S, K, C, v, a, \overline{r})$; otherwise, parse $\func{Coin} = (S, K, C, \overline{r})$.
\item Generate an AEAD encryption key $k_{\text{aead}} = \func{AEADKeyGen}(s_1 K)$ and decrypt $$r = \func{AEADDecrypt}(k_{\text{aead}},\texttt{r},\overline{r});$$ if decryption fails, return failure.
\item If $\func{Coin}$ was generated in a mint transaction, parse the recipient data $r = (d, k, m)$; otherwise, parse $r = (v, a, d, k, m)$.
\item Check that $K = \hash_k(k)\hash_{\text{div}}(d)$, and return failure otherwise.
\item Check that $C = \comm(a,v,\hash_{\text{val}}(k))$, and return failure otherwise.
\item Decrypt the diversifier $i = \func{SymDecrypt}(\func{SymKeyGen}(s_1),d)$.
\item Check that $$S = \comm(\hash_{\text{ser}}(k),0,0) + \comm(\hash_{Q_2}(s_1,i),0,0) + P_2,$$ and return failure otherwise.
\item Output $(v, m, a, i, k)$.
\end{enumerate}

\subsection{\texorpdfstring{$\func{Spend}$}{Spend}}

This algorithm allows a recipient to generate a transaction that consumes coins it controls, and generates new coins destined for arbitrary public addresses.
A spend transaction spends coins of two asset types separately; one is a generic asset type (where the type itself is hidden), and the other is the base asset type.
This ensures that fees can be denominated consistently and publicly.

It is assumed that the recipient has run the $\func{Recover}$ algorithm on all coins that it wishes to consume in such a transaction.

\textbf{Inputs:}
\begin{itemize}
    \item A full view key $\addr_{\text{full}}$
    \item A spend key $\addr_{\text{sk}}$
    \item A set of $N$ input coins $\func{GenericInCoins}$, of generic asset type, as part of a cover set
    \item A set of $N$ input coins $\func{BaseInCoins}$, of base asset type, as part of a cover set
    \item For each $u \in [0,\underline{w})$ coin of generic type $a \neq 0$ to spend, the index in $\func{GenericInCoins}$, serial number, tag, value, and nonce: $(\underline{l}_u, \underline{s}_u, \underline{T}_u, \underline{v}_u, \underline{k}_u)$
    \item For each $u \in [0,w)$ coin of base type $a = 0$ to spend, the index in $\func{BaseInCoins}$, serial number, tag, value, and nonce: $(l_u, s_u, T_u, v_u, k_u)$
    \item An integer fee value $f \in [0,v_{\text{max}})$
    \item A set of $\underline{t}$ generic-type output coin public addresses, values, and memos: $$\{\underline{\addr}_{\text{pk},j}, \underline{v}_j, \underline{m}_j\}_{j=0}^{t-1}$$
    \item A set of $t$ base-type output coin public addresses, values, and memos: $$\{\addr_{\text{pk},j}, v_j, m_j\}_{j=0}^{t-1}$$
\end{itemize}

\textbf{Outputs:} Spend transaction $\text{tx}_{\text{spend}}$

\begin{enumerate}
    \item Parse the required full view key component $D$ from $\addr_{\text{full}}$.
    \item Parse the spend key $\addr_{\text{sk}} = (s_1, s_2, r)$.
    \item Parse the cover set serial number commitments and value commitments $\{(S_i, C_i)\}_{i=0}^{N-1}$ from $\func{BaseInCoins}$ and $\{(\underline{S}_i, \underline{C}_i)\}_{i=0}^{N-1}$ from $\func{GenericInCoins}$.
    \item For each $u \in [0,w)$:
    \begin{enumerate}
        \item Compute the serial number commitment offset: $$S_u' = \comm(s_u, 0, -\hash_{\text{ser}'}(s_u, D)) + D$$
        \item Compute the value commitment offset: $$C_u' = \comm(0, v_u, \hash_{\text{val}'}(s_u, D))$$
        \item Generate a parallel one-out-of-many proof:
        \begin{multline*}
        (\Pi_{\text{par}})_u = \func{ParProve}(pp_{\text{par}},\{S_i, C_i\}_{i=0}^{N-1}, S_u',C_u'; \\
        (l_u, \hash_{\text{ser}'}(s_u, D), \hash_{\text{val}}(k_u) - \hash_{\text{val}'}(s_u, D)))
        \end{multline*}
    \end{enumerate}
    \item For each $u \in [0,\underline{w})$:
    \begin{enumerate}
        \item Compute the serial number commitment offset: $$\underline{S}_u' = \comm(\underline{s}_u, 0, -\hash_{\text{ser}'}(\underline{s}_u, D)) + D$$
        \item Compute the value commitment offset: $$\underline{C}_u' = \comm(a, \underline{v}_u, \hash_{\text{val}'}(\underline{s}_u, D))$$
        \item Generate a parallel one-out-of-many proof:
        \begin{multline*}
        (\underline{\Pi}_{\text{par}})_u = \func{ParProve}(pp_{\text{par}},\{\underline{S}_i, \underline{C}_i\}_{i=0}^{N-1}, \underline{S}_u',\underline{C}_u'; \\
        (\underline{l}_u, \hash_{\text{ser}'}(\underline{s}_u, D), \hash_{\text{val}}(\underline{k}_u) - \hash_{\text{val}'}(\underline{s}_u, D)))
        \end{multline*}
    \end{enumerate}
    \item Generate a set $\func{BaseOutCoins} = \{\func{CreateCoin}(\addr_{\text{pk},j}, v_j, m_j, 0, 0)\}_{j=0}^{t-1}$ of base-type output coins.
    \item Generate a set $\func{GenericOutCoins} = \{\func{CreateCoin}(\underline{\addr}_{\text{pk},j}, \underline{v}_j, \underline{m}_j, a, 0)\}_{j=0}^{\underline{t}-1}$ of generic-type output coins.
    \item Parse the coin value commitments $\{\overline{C}_j\}_{j=0}^{t-1}$ from $\func{BaseOutCoins}$, where each $\overline{C}_j$ is associated to nonce $\overline{k}_j$.
    \item Parse the coin value commitments $\{\underline{\overline{C}}_j\}_{j=0}^{\underline{t}-1}$ from $\func{GenericOutCoins}$, where each $\underline{\overline{C}}_j$ is associated to nonce $\underline{\overline{k}}_j$.
    \item Generate an aggregated range proof for all output coins:
    \begin{multline*}
        \Pi_{\text{rp}} = \func{RangeProve}\left( pp_{\text{rp}}, \{\overline{C}_j\}_{j=0}^{t-1} \cup \{\underline{\overline{C}}_j\}_{j=0}^{\underline{t}-1} ; \right. \\
        \left. \{(0, v_j, \hash_{\text{val}}(\overline{k}_j))\}_{j=0}^{t-1} \cup \{(a, \underline{v}_j, \hash_{\text{val}}(\underline{\overline{k}}_j))\}_{j=0}^{\underline{t}-1} \right)
    \end{multline*}
    \item Generate a proof that all base-type assets have $a = 0$: $$\Pi_{\text{base}} = \func{AggProve}\left( pp_{\text{agg}}, \{\overline{C}_j\}_{j=0}^{t-1} ; (\{v_j, \hash_{\text{val}}(\overline{k_j})\}_{j=0}^{t-1}) \right)$$
    \item Generate a proof that all generic-type coins have the same type:
    \begin{multline*}
        \Pi_{\text{type}} = \func{TypeProve}\left( pp_{\text{type}}, \{\underline{C}'_u\}_{u=0}^{\underline{w}-1} \cup \{\underline{\overline{C}}_j\}_{j=0}^{\underline{t}-1} ; \right. \\
        \left. \left(a, \{\underline{v}_u, \hash_{\text{val}'}(\underline{s}_u,D)\}_{u=0}^{\underline{w}-1} \cup \{\underline{v}_j, \hash_{\text{val}}(\underline{\overline{k}}_j)\}_{j=0}^{\underline{t}-1}\right) \right)
    \end{multline*}
    \item Generate representation proofs for balance assertion:
    \begin{multline*}
    \Pi_{\text{bal}} = \func{RepProve}\left( pp_{\text{rep}}, H, \sum_{u=0}^{w-1} C_u' - \sum_{j=0}^{t-1} \overline{C}_j - \comm(0,f,0); \right. \\
    \left. \sum_{u=0}^{w-1} \hash_{\text{val}'}(s_u,D) - \sum_{j=0}^{t-1} \hash_{\text{val}}(\overline{k}_j) \right)
    \end{multline*}
    \begin{multline*}
    \underline{\Pi}_{\text{bal}} = \func{RepProve}\left( pp_{\text{rep}}, H, \sum_{u=0}^{\underline{w}-1} \underline{C}_u' - \sum_{j=0}^{\underline{t}-1} \underline{\overline{C}}_j; \right. \\
    \left. \sum_{u=0}^{\underline{w}-1} \hash_{\text{val}'}(\underline{s}_u,D) - \sum_{j=0}^{\underline{t}-1} \hash_{\text{val}}(\underline{\overline{k}}_j) \right)
    \end{multline*}
    \item Define the following binding hash:
    \begin{multline*}
        \mu = \hash_{\text{bind}}( \func{BaseInCoins}, \func{GenericInCoins}, \func{BaseOutCoins}, \func{GenericOutCoins}, \\
        \left\{ S_u', C_u', T_u, (\Pi_{\text{par}})_u, \right\}_{u=0}^{w-1}, \left\{ \underline{S}_u', \underline{C}_u', \underline{T}_u, (\underline{\Pi}_{\text{par}})_u, \right\}_{u=0}^{\underline{w}-1}, \\
        \Pi_{\text{base}}, \Pi_{\text{rp}}, \Pi_{\text{bal}}, \underline{\Pi}_{\text{bal}}, \Pi_{\text{type}} )
    \end{multline*}
    \item Generate a modified Chaum-Pedersen proof, where we additionally bind $\mu$ to the initial transcript:
    \begin{multline*}
    \Pi_{\text{chaum}} = \func{ChaumProve}((pp_{\text{chaum}}, \mu), \{S_u', T_u\}_{u=0}^{w-1} \cup \{\underline{S}_u', \underline{T}_u\}_{u=0}^{\underline{w}-1}; \\
    (\{s_u, r, -\hash_{\text{ser}'}(s_u, D)\}_{u=0}^{w-1} \cup \{\underline{s}_u, r, -\hash_{\text{ser}'}(\underline{s}_u, D)\}_{u=0}^{\underline{w}-1}))
    \end{multline*}
    \item Output the tuple:
    \begin{multline*}
    \text{tx}_{\text{spend}} = ( \func{BaseInCoins}, \func{GenericInCoins}, \func{BaseOutCoins}, \func{GenericOutCoins}, \\
    f, \left\{ S_u', C_u', T_u, (\Pi_{\text{par}})_u \right\}_{u=0}^{w-1}, \left\{ \underline{S}_u', \underline{C}_u', \underline{T}_u, (\underline{\Pi}_{\text{par}})_u \right\}_{u=0}^{\underline{w}-1}, \\
    \Pi_{\text{base}}, \Pi_{\text{rp}}, \Pi_{\text{bal}}, \underline{\Pi}_{\text{bal}}, \Pi_{\text{type}}, \Pi_{\text{chaum}} )
    \end{multline*}
\end{enumerate}

Observe that this effectively maintains two ``pools" of coins available for cover sets.
Coins minted with $a = 0$, or those generated in spends produced by consuming base-type coins, are the only coins used for producing $\func{BaseInCoins}$ cover sets.
Coins minted with $a \neq 0$, or those generated in spends produced by consuming generic-type coins, are the only coins used for $\func{GenericInCoins}$ cover sets.

Also note that it is possible to aggregate all output coin range proofs using a suitable range proving system; this is particularly relevant for designs like those of \cite{bp,bp_plus} that scale logarithmically in size for aggregation purposes.

Transaction verification is modified in a straightforward manner to verify the relevant proofs.

\section{Efficiency}

We briefly outline the efficiency of Spats compared to the original Spark protocol.
Table \ref{table:size_mint} shows the change in size of mint transaction components, and Table \ref{table:size_spend} shows the change in size of spend transaction components.
We assume throughout that both group and scalar elements have $32$-byte representations, and that asset type identifiers are restricted to $\tau$ bytes.

\begin{table}[ht]
    \centering
    \begin{tabular}{|l|r|r|r|}
    \hline
    \textbf{Component} & \textbf{$\Delta\G$} & \textbf{$\Delta\F$} & \textbf{$\Delta$ bytes} \\
    \hline
    $a$ & &  & $\tau\underline{t}$ \\
    \hline
    Total & & & $\tau\underline{t}$ \\
    \hline
    \end{tabular}
    \caption{Mint transaction size change by component ($\underline{t}$ generated generic-type coins)}
    \label{table:size_mint}
\end{table}

\begin{table}[ht]
    \centering
    \begin{tabular}{|l|r|r|r|}
    \hline
    \textbf{Component} & \textbf{$\Delta\G$} & \textbf{$\Delta\F$} & \textbf{$\Delta$ bytes} \\
    \hline
    $\Pi_{\text{rp}}$ & & $1$ & \\
    $\Pi_{\text{bal}}$ & & $1$ & \\
    $\underline{\Pi}_{\text{bal}}$ & $1$ & $2$ & \\
    $\Pi_{\text{base}}$ & $2$ & $2$ & \\
    $\{\overline{r}_j\}$ & & & $\tau\underline{t}$ \\
    $\Pi_{\text{type}}$ & $2$ & $5$ & \\
    \hline
    Total & $5$ & $11$ & $\tau \underline{t}$ \\
    \hline
    \end{tabular}
    \caption{Spend transaction size change by component ($\underline{t}$ generated generic-type coins)}
    \label{table:size_spend}
\end{table}

A mint transaction with $\underline{t}$ generated generic-type coins increases by $\tau\underline{t}$ bytes.
A spend transaction with $\underline{t}$ generated generic-type coins increases by $512 + \tau t$ bytes.

\bibliographystyle{plain}
\bibliography{main}

\end{document}


% This file is part of the TGASplus project.
% Copyright 2016 the authors.

% ## Style notes
% - Use n-dash (--) for color--magnitude diagram.

% ## To-do
% - Draft method section
% - Get and write up results
% - Put in all figures
% - Draft discussion
% - Find all HOGG, XXX, DWH, CITE, and fix these
% - What does ``stationary'' mean?

\documentclass[12pt]{article}
\usepackage{url}

% text definitions
\include{gitstuff}
\newcommand{\documentname}{\textsl{Paper}}
\newcommand{\project}[1]{\textsl{#1}}
\newcommand{\acronym}[1]{\small{#1}}
\newcommand{\gaia}{\project{Gaia}}
\newcommand{\tgas}{\project{\acronym{TGAS}}}
\newcommand{\twomass}{\project{\acronym{2MASS}}}
\newcommand{\wise}{\project{All\acronym{WISE}}}
\newcommand{\wone}{W\!\mathit{1}}

% math definitions
\newcommand{\given}{\,|\,}
\newcommand{\normal}{\mathcal{N}}
\newcommand{\setof}[1]{\{{#1}\}}
\newcommand{\pc}{\mathrm{pc}}

% typographic style stuff
\setlength{\textheight}{9in}
\setlength{\topmargin}{-0in}
\setlength{\headheight}{0ex}
\setlength{\headsep}{0ex}
\setlength{\oddsidemargin}{\topmargin}
\urlstyle{sf}
\linespread{1.08}
\frenchspacing
\sloppy\sloppypar\raggedbottom

\begin{document}

\section*{Far, far better distances for Gaia stars}

\noindent
DWH, DSTN, others?

\paragraph{Abstract:}
% Context:
Given that the color--magnitude diagram of stars is highly informative, the
best measure of a \gaia\ \tgas\ Catalog star's distance will not be based on
its tabulated parallax measurement alone (or even at all):
The star's color and magnitude are both very informative too.
Furthermore, because of statistical shrinkage, the colors, magnitudes,
and parallaxes of all the \emph{other} stars in the Catalog are \emph{also}
informative.
% Aims:
Here we make use of both of these pieces of information---but no
physical models of stars whatsoever---to greatly improve our distance
estimates for \gaia\ \tgas\ stars.

% Methods:
For each object star in \tgas, we find the $K=128$ most nearby \tgas\ stars
in a \gaia--\twomass--\wise\ color--color space.
We build a noise-deconvolved model of the \gaia\ $G$-band absolute
magnitude distribution of these same-color stars, properly accounting
for the parallax uncertainties.
This model is a mixture of Gaussians in absolute magnitude, and the
mixture parameters are set by optimizing a marginalized likelihood,
which in turn is computed by post-processing a posterior sampling made
under an interim prior.
We use this noise-deconvolved model---which is very informative---to
build a prior on distance for the object star and generate posterior
beliefs about (and a posterior sampling of) its distance.
This method is a leave-one-out approximation to a hierarchical model for
a patch of the color--magnitude diagram.

% Results:
The posterior pdfs we generate for distance for typical \tgas\ stars
are more informative (more precise) by a factor of XXX relative to any
comparable analysis of the star's parallax measurement alone.
Everything we do here can be done, only far better, for subsequent
\gaia\ data releases.

\section{Introduction}

A parallax is a direct, geometric measurement of the distance to a star.
For this reason it is a beautiful piece of information: It can be used
to infer a stellar distance without resort to any physical or
theoretical beliefs about the evolution, dynamics, structure, or
photospheres of stars.
That's sick, and makes astronomers very confident about parallax-based
distance inferences and the science built thereon.

While we agree that it is very valuable to obtain as much information
as possible about stellar distances and the distance scale without
resort to (necessarily imperfect) stellar models, we disagree that the
best model-free estimate of a star's distance involves the parallax
alone.
Not only is the \emph{photometry} of the star---the color across
multiple bands---also relevant, the photometry and parallaxes of
\emph{all other stars} are \emph{also} highly relevant.
The idea is a simple consequence of the concept of \emph{statistical shrinkage}:
If stars are generated by a straightforward, stationary process---that
is, if for every star in the Galaxy there are many other very similar
stars---then the noisy parallaxes of all other stars with similar
photometric properties are highly relevant to the inverse parallax
(distance) of the star in question.

\begin{figure}[p]
~~
\caption{The color--magnitude diagram of stars in \tgas\ and matched
  to \twomass. We only show stars that have parallaxes measured at a
  signal-to-noise greater than 32. The distance modulus estimate is
  described (WHERE HOGG?) and the extinction corrections are described
  (WHERE HOGG?).\label{fig:cmd}}
\end{figure}

One way to see this is to naively plot the color-magnitude diagram of
stars in the \gaia\ \acronym{DR1} \tgas\ catalog of parallaxes and
photometry, after joining with \twomass\ or \wise\ to get colors.
The resulting diagram is shown for some signal-to-noise cuts in
\figurename~\ref{fig:cmd}.
This color--magnitude diagram is incredibly informative, and was built
without the use of any knowledge of stellar physics or any stellar models at all.
To ignore this photometric information is obviously a mistake, especially for
stars with very noisy parallax measurements.
Of course \figurename~\ref{fig:cmd} was built with improper distance
inferences; the distances used to make that color-magnitude diagram
are just point estimates of distance given parallaxes.
We shouldn't use such point estimates when it is straightforward to
use the parallax likelihood functions responsibly to propagate the noisy
information they provide about distances (CITE CBJ).

In this \documentname, we use the parallax likelihood correctly, and also the
color--magnitude information about \emph{all} stars, to infer every
individual star's distance responsibly.
We don't go full Bayes at all levels of the hierarchy of our model,
but we are careful not to ``use the data twice''.
There are no conceptual roadblocks to doing a full hierarchical
probabilistic inference in the future.
Despite our shortcuts, we produce extremely informative and highly
predictive posterior pdfs for stellar distances.
Our distance estimates are far better than those made considering the
parallax alone (CITE CBJ), despite including absolutely no new
information about stellar physics or theory.

\section{Assumptions and method}

The \tgas\ Catalog (CITE) contains $N=XXX$ stars $n$, each of which has (for
our purposes) a magnitude $G_n$, a measured parallax $\varpi_n$, and
an uncertainty $\sigma_n$ on that parallax.
Each of these stars (with a few exceptions) can be matched to entries
in the \twomass\ Catalog (CITE) and the \wise\ Catalog (CITE), from
which we can get infrared $J$ and $\wone$ magnitudes.
We extinction-corrected the photometry by XXX YYY HOGG; we excluded
the XXX stars for which these corrections exceeded XXX\,mag.
We visualize the resulting data in \figurename~\ref{fig:data}.
%
\begin{figure}[p]
~~
\caption{The data used in this project.\label{fig:data}}
\end{figure}

In what follows, we make a set of well-defined assumptions, build and
execute a method that is justified under those assumptions, and then
(at the end) criticize the assumptions and the results that flow therefrom.
The assumptions are as follows:
\begin{enumerate}\itemsep=0ex
\item For typical stars taken from the \tgas\ Catalog, the parallax
  uncertainty is larger in an absolute-magnitude sense than the
  uncertainty in the $G$, $J$, $\wone$, or relevant dust extinction. That
  is, we can ignore photometric uncertainties relative to astrometric
  uncertainties.
\item For every object star $n$, there are $K$ nearby neighbors in
  $(G-J, G-\wone)$ color space that are both sufficiently close that they
  are drawn from the same absolute magnitude distribution as star $n$,
  but sufficiently numerous that they can support a model for their
  distribution.
\item We have an interim prior on stellar distances for \tgas\ stars
  that has support at all reasonable distances, and we have a
  $T$-sample sampling of distance $d$ for every star under that
  interim prior.
\end{enumerate}

We bat around the following equations:
\begin{eqnarray}
  d_{kt} &\sim& p(d\given\varpi_k,\theta_0)
  \\
  p(d\given\theta_0) &=& \frac{1}{Z}\,d^2\,\exp(-\frac{d^2}{L^2})
  \\
  p(M_G\given\alpha_n) &=& \sum_{q=1}^Q a_q\,\normal(M_G\given\mu_q,V_q)
  \\
  \alpha_n &=& \setof{a_q, \mu_q, V_q}_{q=1}^Q
  \\
  1 &=& \sum_{q=1}^Q a_q
  \\
  p(d\given\alpha_n) &\propto& \frac{1}{d}\,p(M_G\given\alpha_n)
  \\
  M_G &\equiv& G - A_G - 5\,\log_{10}(\frac{d}{10\,\pc})
  \\
  p(\alpha_n\given\varpi_k) &\propto& \frac{1}{T}\,\sum_{t=1}^T \frac{p(d_{kt}\given\alpha_n)}{p(d_{kt}\given\theta_0)}
  \\
  \ln p(\alpha_n\given\Pi_n) &=& \sum_{k=1}^K p(\alpha_n\given\varpi_k)
  \\
  \Pi_n &\equiv& \setof{\varpi_k}_{k=1}^K
\end{eqnarray}

\section{Results and discussion}
We ran on everything and got XXX.

Here are some plots comparing to CBJ-style inferences.

HOGG: How much better when we get BpRp and RVS!

All the data used in this project are public. All the code used in
this project is open-source. The main codebase is licensed under the
\project{\acronym{MIT} License} and available at
\url{https://github.com/davidwhogg/TGASplus}. This version of the
manuscript and figures was made at git hash
\textsf{\githash\,(\gitdate)}.

\paragraph{Acknowledgements:}
It is a pleasure to thank
  Jo Bovy (Toronto),
  and
  Dan Foreman-Mackey (UW)
for valuable advice and discussions.
We are funded by (HOGG: various agencies).

\end{document}


% Generated by GrindEQ Word-to-LaTeX 2008
% ========== UNREGISTERED! ========== Please register! ==========
% LaTeX/AMS-LaTeX

\documentclass[a4paper]{article}
\usepackage{anysize}
\marginsize{1cm}{1cm}{1cm}{1cm}

\usepackage{amssymb}
\usepackage{amsmath}
\usepackage[dvips]{graphicx}
\usepackage{listings}
\lstset{language=haskell}
\lstset{commentstyle=\textit}
\lstset{mathescape=true}
%\lstset{labelstep=1}
%\lstset{backgroundcolor=,framerulecolor=}
\lstset{backgroundcolor=,rulecolor=}
\linespread{2.0}

\begin{document}

\title{Customizable Objects}

\textit{Giuseppe Maggiore}
\textit{Michele Bugliesi}
\textit{Universitá Ca'  Foscari -- Venice}

\section{Motivation}

We wish to introduce a series of constructs that allow us to write object-oriented programs that are capable of running with
very different runtime behaviors with minimal to zero modification of the program. Our constructs (characterized by a type
class $Heap$) are:
\begin{itemize}
\item a storage (heap) $h$
\item a reference to a location in the storage $ref$
\item an allocation operator $>>+$ for values inside the heap
\item a program statement $st$
\item an evaluation operator $eval$
\item an assignment operator $:=$
\item a selection operator for fields and methods $\Leftarrow$
\end{itemize}

We also give a subtyping and an inheritance relation for polymorphism.

Thanks to these constructs we can write generic object-oriented programs. We show how different concrete implementations
of the $Heap$ class can be given that allow highly varying execution schemes.

The first execution scheme is a simple mutable program that manipulates references to $Point3D$, which inherits from $Point2D$:
\begin{lstlisting}[frame=tb,mathescape]{somecode}
length2d : Label Point2D (Method Point2D Unit Float)
length3d : Label Point3D (Method Point3D Unit Float)
normalize : Label Point3D (Method Point3D Unit Unit)

f : Heap h ref st, Point3D $\le$ Point2D $\Rightarrow$ ref h Point 3D $\to$ st h float
f p =
  do  l $\leftarrow$ (p $\Leftarrow$ length3d) ()
      (p $\Leftarrow$ normalize) ()
      l' $\leftarrow$ (p $\Leftarrow$ length2d) ()
      return l / l'

v = runMutable (do (newPoint3D 1.0 2.0 -1.0) >>+ f)
\end{lstlisting}

In this example $v$ will be equal to the original length of the vector divided by the length of the $x,y$ vector after normalizing it in three
dimensions.

As another example let us consider some code that performs operations on a bank account. This code makes us of an extension to our
system, that is the $Transactional$ predicate on our statements that allows us to use the $beginT$, $abortT$ and $commitT$ statements
that respectively mark the beginning of a transaction and its end by failure or success:

\begin{lstlisting}[frame=tb,mathescape]{somecode}
get_balance : Label Account (Method Account Unit Int)
withdraw : Label Account (Method Account Int Unit)
deposit : Label Account (Method Account Int Unit)

banker : Heap h ref st, Transactional st $\Rightarrow$ [Int] $\to$ [Int] $\to$ ref h Account
banker ws ds account =
  do  begintT
      transactions ws ds account
      b $\leftarrow$ (account $\Leftarrow$ get_balance) ()
      return b
  where transactions [] [] =
          do  b $\leftarrow$ (account $\Leftarrow$ get_balance) ()
              if b < 0 then abortT
              else commitT
        transactions (w:ws) [] =
          do  (account $\Leftarrow$ withdraw) w
              transactions ws []
        transactions ws (d:ds) =
          do  (account $\Leftarrow$ deposit) d
              transactions ws ds

v = runMutable (do (newAccount 100) >>+ banker [10;5;700] [200;500;240])
\end{lstlisting}

where we expect that the transaction will fail and $v = 100$.

We can also express concurrent computations where assignment corresponds to sending a value and evaluation corresponds to
receiving one from a network channel; the $Concurrent$ predicate also allows us to use the $fork$ and $sleep$ statements:

\begin{lstlisting}[frame=tb,mathescape]{somecode}
main : Heap h ref st, Concurrent st $\Rightarrow$ st h ()
main =
  0 >>+ ($\lambda$channel.
      fork (p1 channel 0)
           (p2 channel))
  where p1 channel i =
          do  channel := i -- send
              sleep 1000
              i' $\leftarrow$ eval channel -- receive
              p1 channel (i'+1)
        p2 channel =
          do  i $\leftarrow$ eval channel -- receive
              channel := (i*2)
              p2 channel

runConcurrent main
\end{lstlisting}

where we expect the code to never stop running while the two processes continuosly exchange messages.

Finally we show how we can express reactive programs that are capable of automatically updating certain values where those they depend from get modified;
the $Reactive$ predicate enables the reactive operators $!=$ for assignment and $!+$ for sum:

\begin{lstlisting}[frame=tb,mathescape]{somecode}
f : Num a, Heap h ref st, Reactive ref $\Rightarrow$ ref h a $\to$ ref h a $\to$ ref h a $\to$ st h a
f a b c =
  do  b := 10
      c := -5
      a != b !+ c
      x $\leftarrow$ a
      b := 5
      x' $\leftarrow$ a
      return (x,x')

v = runReactive (do 0 >>+ ($\lambda$a.0 >>+ ($\lambda$b.0 >>+ ($\lambda$c.f a b c))))
\end{lstlisting}

where we expect our program to return (5,0) since reassigning $b$ automatically modifies the value of $a$ which depends from it.

These are by no means the only possible applications of our system. Not only these can be combined (for example to form transactional and
concurrent programs) through monad transforms, but also many more applications could be found.

\end{document}

% == UNREGISTERED! == GrindEQ Word-to-LaTeX 2008 ==