\documentclass{article}
\usepackage{amsmath}
\usepackage{mathrsfs}
\usepackage{amssymb} % for "\mathbb" macro
\usepackage[round]{natbib}
\usepackage{url}
\usepackage{hyperref}
\usepackage[toc,page]{appendix}

\title{Multi-Factor Commodity Price Process: Spot and Forward Price Simulation}
\author{Jake C. Fowler}
\date{January 2020}

\begin{document}
\newcommand{\+}[1]{\ensuremath{\mathbf{#1}}}

\maketitle

WARNING: THIS DOCUMENT IS CURRENTLY WORK IN PROGRESS

\tableofcontents

\newpage

\section{Introduction}
This document describes a very general multi-factor commodity price process model,
together with some analytical results which can be used to explore the assumed
price dynamics, and simulate prices computationally when performing a Monte-Carlo
simulation.

\subsection{Forward Price SDE}
The starting point is the SDE (stochastic differential equation) for the forward
price process:

\begin{align}
    \label{eq:forward_sde}
    \frac{dF(t, T)^l}{F(t, T)^l}=\sum_{i=1}^{n^l} \sigma_i^l(T)e^{-\alpha_i^l(T-t)}dz_i^l(t) \\
    \nonumber
    \alpha_i^l \in \mathbb{R}_{\ge 0} \\
    \nonumber
    t \in \mathbb{R}_{\ge 0} \\
    \nonumber
    T \in \{ T_0^l, T_1^l, T_2^l, \hdots | T_j^l \ge t  \} \\
    \nonumber
    \sigma_i^l : \mathbb{R}_{\ge 0} \rightarrow \mathbb{R} \\
    \nonumber
    l \in [1, m]
\end{align}

Where $z_i^l(t)$ follow correlated Wiener processes with correlation $\rho_{i, j}^{x, y}$, i.e.

\begin{equation}
    \mathbb{E}[dz_i^x(t)dz_j^y(t)] = \rho_{i, j}^{x, y}dt
\end{equation}

$F(t, T_j)^l$ is the forward price observed at time $t$, for delivery over the time
interval $[T_j, T_{j+1})$ of the $l^{\text{th}}$ of $m$ commodity underlyings.
Note for the majority of equations in the rest of this text, in order to lighten
notation, the $l$ superscript is dropped and results are given for the single-commodity
case. Where relevant the $l$ superscript will be introduced to illustrate the model
behaviour in a multi-commodity context.

\subsection{Comparison With Other Models}

This model is almost a specific case of the general multi-factor model presented
in \cite{Clewlow}, which instead of a coefficients of the Wiener process being
$\sigma_i(T)e^{-\alpha_i(T-t)}$ as presented here, uses the more general form
$\sigma_i(t, T)$. As results presented below show, the advantage of the form
used in this paper is that the future distribution of forward and spot prices
can be derived analyticallly. Another difference is that the cited paper assumes
the driving stochastic factors
are uncorrelated Wienver processes, whereas the model presented here uses correlated
Brownian motions.

\bigskip

The model is also similar to that presented in \cite{Warin} except that the $\sigma_i$
volatility in this model is a function of forward maturity date $T$, rather than
ovservation date $t$ in \cite{Warin}.

\subsection{Analysis of Model}
The following observations can be made about this model:

\begin{itemize}
    \item Forward prices are lognormally distributed, which has the following practical
    considerations:
    \begin{itemize}
        \item The model doesn't take into account volatility smile. This assumption is
        acceptable for modelling commodities which do not have a liquid market in vanilla
        options. It is also an acceptable to model the price dynamics as part of a pricing
        and/or optimisation model for a complex physical product which isn't sensitive
        to changes in the shape of the skew surface. For example this model probably isn't
        suitable for pricing Asian options on Brent crude oil as the vanilla options market
        is liquid enough to be able to extract a volatility surface (i.e. implied volatility
        by expiry and maturity) in order to calibrate a price dynamics model which take the surface into account
        (e.g. a stochastic volatility model) for use in pricing a relativeley simple product like
        Asian options. Potentially this model is suitable for the price dynamics part of a
        more complex model for
        optimising a physical oil asset such as an oil refinery, where the
        practical implementation of the optimisation algorithm is only possible with a relatively
        simple deterministic volatility model, such as the one presented here. A similar reasoning
        could be used to jusfify the suitability for use for pricing gas storage, swing, and
        power generation assets, as these require complex optimisation. But the reason would
        be even more justified for use with these products in in many European markets,
        where the vanilla options
        markets either does not exist, or are not liquid enough to reliably calibrate a
        stochastic volatility model.
        \item The price of some commodities can occasionally go negative, for example
        power and natural gas. Whether this model is suitable depends on the frequency
        of such negative price occurances, and whether the use of the model is impacted
        by this. For example it definetely shouldn't be used to price half-hourly exercise
        European options on the spot power with strike price $\leq 0$.
    \end{itemize}
    \item The model is fitted to the forward curve, i.e. the expected spot price
    is equal to the equivalent point on the initial curve. This makes the model suitable
    for use under the risk-neutral probability measure, assuming deterministic interest
    rates.
    \item There are $n$ sources of uncertainty for which the effect on $F(t, T)$
    depends on the following parameters:
    \begin{itemize}
        \item The impact of each factor's movement on forward prices decays exponentially
        with time to maturity (i.e. $T-t$) with the $\alpha_i$ parameter determining the
        rate of this decay. A higher $\alpha_i$ results in a more rapid decay, and the minimum
        possible value of zero for $\alpha_i$ means that movements in the $i^\text{th}$
        stochastic factor result in
        non-decaying parrallel shifts in the whole forward curve, assuming $\sigma_i(T)$
        returns a constant value. As the derivation of the spot price process shows
        below, in terms of spot price dynamics $\alpha_i$ translates to the mean reversion
        rate of the $i^\text{th}$ stochastic factor driving the spot price.
        \item $\sigma_i$ is an arbitray maturity dependent volatility function. This parameter
        can be used to control seasonality in the volatility and correlation of the forward
        prices. For example a $\sigma_i$ function which only returns non-zero values for $T$
        which are in the Winter delivery periods would make the $i^\text{th}$ factor only
        drive Winter forward prices. $\sigma_i$ could also be used during parameter calibration
        to impose a scaling factor such that the model exactly matches at-the-money implied
        volatilities. A similar calibration step is described in \cite{Rebonato}, p. 673,
        although in the context of an LMM-style model.
    \end{itemize}
\end{itemize}

\section{Analytical Result on Distribution of Prices}
\subsection{Forward Price Distrubtion}
Integrating this SDE (see Appendix \ref{appendix:forward_sde_integrate}):

\begin{equation}
    \label{eq:forward_process_integrated}
    F(t_2, T) = F(t_1, t)e^{- \frac{1}{2} V(t_1, t_2, T) + I(t_1, t_2, T)}
\end{equation}

Where:

\begin{equation}
    \nonumber
    V(t_1, t_2, T) = \sum_{i=1}^n \sigma_i(T) \sum_{j=1}^n \sigma_j(T) \rho_{i,j}
    \vartheta_{T-t_1, T-t_2}(\alpha_i + \alpha_j)
\end{equation}

\begin{align}
    \vartheta_{c_1, c_2}(x) =
    \begin{cases}
        \frac{e^{-x c_2} - e^{-x c_1}}{x} & \text{for} \quad x \in \mathbb{R}_{\ne 0} \\
        c_1 - c_2 & \text{for} \quad x=0
    \end{cases}
\end{align}

\begin{equation}
    I(t_1, t_2, T) = \sum_{i=1}^n \sigma_i(T) \int_{t_1}^{t_2} e^{-\alpha_i(T-u)}dz_i(u)
\end{equation}

\subsection{Simulation of Forward Curve}
A more convenient form of \ref{eq:forward_process_integrated} for use in simulating
the evaluation of the whole forward curve between $t_1$ and $t_2$ is:

\begin{equation}
    F(t_2, T) = F(t_1, T)e^{- \frac{1}{2} V(t_1, t_2, T) +
        \sum_{i=1}^n \sigma_i(T) e^{-\alpha_i T} Y_i(t_1, t_2) }
\end{equation}

Where $Y_i(t_1, t_2)$ are normally distributed, with mean zero and covariance:

\begin{equation}
    cov(Y_i(t_1, t_2), Y_j(t_1, t_2)) = \rho_{i, j} \vartheta_{-t_1, -t_2}(\alpha_i + \alpha_j)
\end{equation}

\bigskip

See Appendix \ref{appendix:fwd_sim} for the derivation of this, together with
the equivalent result for the joint simulation of multiple commodities forward curves.

\subsection{Forward Covariance Surface}
A closed form expression exists for the integrated covariances of
forward price log returns. This is derived in Appendix \ref{appendix:fwd_covar}. The evaluation of such
covariances is essential to
understand the statistical properties that the model implies for the dynamics of
the forward curve. It also allows the calibration of model parameters to option
market implied volatilities and historical covariances.
Defining $C(t_1, t_2, T_1, T_2)$
as the integrated covariance from $t_1$ to $t_2$, between the log returns of forward
contracts delivering on respective periods starting on $T_1$ and $T_2$.

\begin{equation}
    C(t_1, t_2, T_1, T_2) = \sum_{i=1}^n \sigma_i(T_1) \sum_{j=1}^n \sigma_j(T_2) \rho_{i,j}
    e^{-\alpha_i T_1 -\alpha_j T_2} \vartheta_{-t_1, -t_2}(\alpha_i + \alpha_j)
\end{equation}

See Appendix \ref{appendix:fwd_covar} for the derivation of this, together with
the equivalent result for the joint simulation of multiple commodities forward curves.

\subsection{Spot Price Distribution}
The spot price $S(t)$ is defined as the price for delivery of the commodity in the period
starting at time $t$, observed at time $t$. Appendix \ref{appendix:spot_distribution}
derives an analytical form for the spot price conditional on the  filtration
$\mathcal{F}_{t_{k-1}}$:

\begin{equation}
    S(t_k) = S(t_{k-1}) \frac{F(0, t_k)}{F(0, t_{k-1})} e^{- \frac{1}{2} (V_s(t_k) -
    V_s(t_{k-1})) + \sum_{i=1}^n \bigl(\sigma_i(t_k)f_i(t_k) - \sigma_i(t_{k-1})f_i(t_{k-1})\bigr)}
\end{equation}

Where $f(t)$ is defined recursively as:

\begin{equation}
    f_i(t_k) = e^{-\alpha_i(t_k - t_{k-1})}f_i(t_{k-1}) + Z_i(t_k)
\end{equation}

With base case:

\begin{equation}
    f_i(0) = 0
\end{equation}

$Z_i(t_k)$ is multivariate normally distributed, with mean zero and covariance:

\begin{equation}
    cov(Z_i(t_k), Z_j(t_k)) = \rho_{i, j} \vartheta_{t_k-t_{k-1}, 0}(\alpha_i + \alpha_j)
\end{equation}

Appendix \ref{appendix:spot_distribution} gives the equivalent result for the case
of multiple commodities.

\bigskip

$f_i(t)$ can be recognised as an Ornstein–Uhlenbeck process with zero drift,
mean reversion parameter $\alpha_i$, and $\sigma$ (coeffient of Brownian motion) of 1.

Except in the case of $n$ being equal to one, it can be seen % TODO add equation reference
that the spot price is not Markovian itself, but is Markovian with respect to the
$n$ state variables $f_i$.

% TODO describe significant for LSMC pricing method

This has practical significance for two reasons. Firstly, when simulating only the
spot price, it is necessary to simulate the $n$ underlying $f_i$ stochastic factors,
before calculating the spot price from these. If simulating the price for several
futures times, it will be necessary to keep track of all $f_i$ due to their
recursive nature.

Simulating just the spot price, rather than the whole forward curve, is of interest
for physical energy commodity products, such as gas storage, swing contracts
and power generation, as the ultimate cash flows (which are conditional upon the
owners decisions) will derive from the spot price. Hence, when building certain pricing
and optimisation models, the simulation of just the spot price will suffice.
Of course, the whole forward curve could be simulated, with the spot price being taken
as the first point on the curve. However, simulating just the spot price will be
more computationally efficient, if this is all we are interested in.

\newpage
\appendix
\appendixpage
\section{Integration of Forward Price SDE}
\label{appendix:forward_sde_integrate}
This appendix gives the detailed step for integrated the forward price process
SDE, hence getting from \ref{eq:forward_sde} to \ref{eq:forward_process_integrated}.

\bigskip

Using Ito's Lemma to calculate the stochastic differential of the natural logarithm
of the forward price.

\begin{equation}
    \label{eq:ln_forward_sde}
    d\ln(F(t, T)) = \frac{1}{F(t, T)} dF(t, T) - \frac{1}{2}
        \frac{1}{F(t, T)^2} (dF(t, T))^2
\end{equation}

Using the properties of Brownian Motion $(dz(t))^2=dt$ and $dtdz(t)=0$ the forward
price differential squared can be evaluated as follows.

\begin{equation}
    \label{eq:df_squared}
    (dF(t, T))^2 = F(t, T)^2 \sum_{i=1}^n \sum_{j=1}^n \sigma_i(T) \sigma_j(T)
    e^{-(\alpha_i + \alpha_j)(T-t)}\rho_{i,j}dt
\end{equation}

Substituting for $(dF(t, T))^2$ and $dF(t, T)$ in \ref{eq:ln_forward_sde}.

\begin{equation}
    \label{eq:ln_forward_sde_2}
    d\ln(F(t, T)) = \sum_{i=1}^n \sigma_i(T)e^{-\alpha_i(T-t)}dz_i(t) -
    \frac{1}{2} \sum_{i=1}^n \sum_{j=1}^n \sigma_i(T) \sigma_j(T)
    e^{-(\alpha_i + \alpha_j)(T-t)}\rho_{i,j}dt
\end{equation}

The purpose of finding the stochastic differential of $ln(F(t, T))$ is to remove the
$F(t, T)$ coefficient of the Brownian motions, leaving an SDE which can be integrated
to a form where the Ito Integrals have non-stochastic integrands, and hence have a normal
distribution with known mean and variance. Integrating \ref{eq:ln_forward_sde_2}:

\begin{equation}
    \ln(F(t_2, T)) = \ln(F(t_1, t)) - \frac{1}{2} V(t_1, t_2, T) + I(t_1, t_2, T)
\end{equation}

Where:

\begin{eqnarray}
    \label{eq:forward_drift_adjust}
    \nonumber
    V(t_1, t_2, T) =  \sum_{i=1}^n \sigma_i(T) \sum_{j=1}^n
    \sigma_j(T) \rho_{i,j} \int_{t_1}^{t_2} e^{-(\alpha_i + \alpha_j)(T-u)} du\\
    = \sum_{i=1}^n \sigma_i(T) \sum_{j=1}^n \sigma_j(T) \rho_{i,j}
    \frac{1}{\alpha_i + \alpha_j} (e^{-(\alpha_i + \alpha_j)(T-t_2)} -
    e^{-(\alpha_i + \alpha_j)(T-t_1)}) \\
    \nonumber
\end{eqnarray}

And:

\begin{equation}
    I(t_1, t_2, T) = \sum_{i=1}^n \sigma_i(T) \int_{t_1}^{t_2} e^{-\alpha_i(T-u)}dz_i(u)
\end{equation}

\bigskip
There is a problem in that $V(t_1, t_2, T)$ is not defined for the case where
$\alpha_i + \alpha_j = 0$. A continuous extension is required in order for this
case to be allowed. Consider the function $\psi$ which is only defined for
the domain $\mathbb{R}_{\ne 0}$, the set real numbers, excluding zero.

\begin{equation}
    \psi_{c_1, c_2}(x) = \frac{e^{-x c_2} - e^{-x c_1}}{x} \quad  x \in \mathbb{R}_{\ne 0}
\end{equation}

The first step to defining the continous extension is to write $\psi$ as a Taylor Series
about zero.

\begin{equation}
    \psi_{c_1, c_2}(x) = \frac{1 - x c_2 - 1 + x c_1 + O(x^2)}{x}
\end{equation}

Taking the limit of $\psi(x)$ towards zero, the $O(x^2)$ becomes negligible, hence:

\begin{eqnarray}
    \nonumber
    \lim_{x \to 0} \psi_{c_1, c_2}(x) = \frac{1 - x c_2 - 1 + x c_1}{x} \\
    = c_1 - c_2
\end{eqnarray}

Using this, we can define $\vartheta$ as the continous extension of $\psi$:

\begin{align}
    \vartheta_{c_1, c_2}(x) =
    \begin{cases}
        \psi_{c_1, c_2}(x) & \text{for} \quad x \in \mathbb{R}_{\ne 0} \\
        c_1 - c_2 & \text{for} \quad x=0
    \end{cases}
\end{align}

Which in the case of equation for V is:

\begin{align}
    \vartheta_{T-t_1, T-t_2}(x) =
    \begin{cases}
        \psi_{T-t_1, T-t_2}(x) & \text{for} \quad x \in \mathbb{R}_{\ne 0} \\
        t_2 - t_1 & \text{for} \quad x=0
    \end{cases}
\end{align}

\bigskip

Using this, we can redefine $V(t_1, t_2, T)$ to include the case of $\alpha_i$ and
$\alpha_j$ both being equal to zero:

\begin{equation}
    \nonumber
    V(t_1, t_2, T) = \sum_{i=1}^n \sigma_i(T) \sum_{j=1}^n \sigma_j(T) \rho_{i,j}
    \vartheta_{T-t_1, T-t_2}(\alpha_i + \alpha_j)
\end{equation}

Hence the forward price can be expressed as:

\begin{equation}
    F(t_2, T) = F(t_1, t)e^{- \frac{1}{2} V(t_1, t_2, T) + I(t_1, t_2, T)}
\end{equation}

\bigskip
\section{Simulation of Forward Curve}
\label{appendix:fwd_sim}
\subsection{Single Commodity}
To illustrate how the whole forward curve can be simulated, first we shall
introduce $Y(t_1, t_2)$:

\begin{equation}
    Y_i(t_1, t_2) = \int_{t_1}^{t_2} e^{\alpha_iu} dz_i(u)
\end{equation}

This Ito integral can be recognised as one of the stochastic factors from the definition
of $I(t_1, t_2, T)$, with the forward maturity $T$ factored out. The foward price
can then be expressed as:

\begin{equation}
    F(t_2, T) = F(t_1, T)e^{- \frac{1}{2} V(t_1, t_2, T) +
        \sum_{i=1}^n \sigma_i(T) e^{-\alpha_i T} Y_i(t_1, t_2) }
\end{equation}

Where $Y_i(t_1, t_2)$ are normally distributed, with mean zero and covariance:

\begin{equation}
    cov(Y_i(t_1, t_2), Y_j(t_1, t_2)) = \rho_{i, j}  \frac{1}{\alpha_i + \alpha_j}
        (e^{(\alpha_i + \alpha_j)t_2} - e^{(\alpha_i + \alpha_j)t_1})
\end{equation}

Redefining this with a continuous extension to allow $\alpha_i + \alpha_j$ to equal
zero:

\begin{equation}
    cov(Y_i(t_1, t_2), Y_j(t_1, t_2)) = \rho_{i, j} \vartheta_{-t_1, -t_2}(\alpha_i + \alpha_j)
\end{equation}

Using the above form it can be seen that the stochastic evolution of the whole forward curve
from $t_1$ to $t_2$ can be achieved as a function of $n$ generated random numbers.

\subsection{Multiple Commodities}
The simulation of the whole forward curve for multiple commodities can be illustrated
by a simple extension to the single commodity case:

\begin{equation}
    F^l(t_2, T) = F^l(t_1, T)e^{- \frac{1}{2} V^l(t_1, t_2, T) +
        \sum_{i=1}^n \sigma_i^l(T) e^{-\alpha_i^l T} Y_i^l(t_1, t_2) }
\end{equation}

Where $V^l(t_1, t_2, T)$ is defined as being identical to $V(t_1, t_2, T)$, except with
$n$ and $\alpha$ variables being superscripted with $l$, and $\rho$ is superscripted
with $l, l$.
$Y_i^l(t_1, t_2)$ are normally distributed, with mean zero and covariance:

\begin{equation}
    cov(Y_i^x(t_1, t_2), Y_j^y(t_1, t_2)) = \rho_{i, j}^{x, y}
    \vartheta_{-t_1, -t_2}(\alpha_i^x + \alpha_j^y)
\end{equation}

\section{Integrated Forward Covariances}
\label{appendix:fwd_covar}
This section derives a closed form expression for the integrated covariances of
forward price log returns, a quantity is referred to as "terminal covariance" in
\cite{Rebonato}.

\subsection{Single Commodity}
Defining $C(t_1, t_2, T_1, T_2)$
as the integrated covariance from $t_1$ to $t_2$, between the log returns of forward
contracts delivering on respective periods starting on $T_1$ and $T_2$.

\begin{equation}
    C(t_1, t_2, T_1, T_2) = \mathbb{E}\biggl[\ln\biggl(\frac{F(t_2, T_1)}{F(t_1, T_1)} \biggr)
    \ln\biggl(\frac{F(t_2, T_2)}{F(t_1, T_2)} \biggr) \biggr] \\
\end{equation}

Removing the products of stochastic and deterministic terms, as they will be equal to zero:

\begin{equation}
    C(t_1, t_2, T_1, T_2) = \mathbb{E}\bigl[ I(t_1, t_2, T_1) I(t_1, t_2, T_2) \bigr]
\end{equation}

Using the known properties of Ito Integrals:
% TODO put in equation with expection of Ito product inside summation?

\begin{eqnarray}
    \nonumber
    C(t_1, t_2, T_1, T_2) = \sum_{i=1}^n \sigma_i(T_1) \sum_{j=1}^n
    \sigma_j(T_2) \rho_{i,j} e^{-\alpha_i T_1 -\alpha_j T_2}
    \int_{t_1}^{t_2} e^{u(\alpha_i + \alpha_j)} du \\
    = \sum_{i=1}^n \sigma_i(T_1) \sum_{j=1}^n \sigma_j(T_2) \rho_{i,j}
    e^{-\alpha_i T_1 -\alpha_j T_2} \frac{1}{\alpha_i + \alpha_j}
    (e^{t_2(\alpha_i + \alpha_j)} - e^{t_1(\alpha_i + \alpha_j)} )
\end{eqnarray}

Allowing for the case of $\alpha_i$ and $\alpha_j$ both being equal to zero,
as in the previous appendix, a continuous extension is made to redefine the function
$C$:

\begin{equation}
    C(t_1, t_2, T_1, T_2) = \sum_{i=1}^n \sigma_i(T_1) \sum_{j=1}^n \sigma_j(T_2) \rho_{i,j}
    e^{-\alpha_i T_1 -\alpha_j T_2} \vartheta_{-t_1, -t_2}(\alpha_i + \alpha_j)
\end{equation}

\subsection{Multiple Commodities}
Defining $C(t_1, t_2, T_1, T_2, x, y)$
as the integrated covariance from $t_1$ to $t_2$, between the log returns of forward
contracts delivering on respective periods starting on $T_1$ for commodity $x$,
and $T_2$ for commodity $y$, the results in the previous subsection can be updated
to show:

\begin{equation}
    C(t_1, t_2, T_1, T_2, x, y) = \sum_{i=1}^{n^x} \sigma_i^x(T_1) \sum_{j=1}^{n^y}
    \sigma_j^y(T_2) \rho_{i,j}^{x, y}
    e^{-\alpha_i^x T_1 -\alpha_j^y T_2} \vartheta_{-t_1, -t_2}(\alpha_i^x + \alpha_j^y)
\end{equation}

\section{Spot Price Process Distribution and Simulation}
\label{appendix:spot_distribution}
\subsection{Single Commodity}
Defining the spot price $S(t)$ as the price for delivery of the commodity in the period
starting at time $t$, observed at time $t$. Using the equivalence between $S(t)$
and $F(t, t)$ and equation \ref{eq:forward_process_integrated}:

\begin{equation}
    S(t) = F(0, t)e^{- \frac{1}{2} V(0, t, t) + I(0, t, t)}
\end{equation}

When simulating a spot price path it is necessary to know the relationship between
$S(t_k)$ and $S(t_{k-1})$, where $0 \leq t_{k-1} < t_k$. Defining $V_s(t)=V(0, t, t)$ and
$I_s(t)=I(0, t, t)$:

\begin{equation}
    S(t_k) = S(t_{k-1}) \frac{F(0, t_k)}{F(0, t_{k-1})} e^{- \frac{1}{2} (V_s(t_k) -
    V_s(t_{k-1})) + I_s(t_k) - I_s(t_{k-1})}
\end{equation}

Focussing on the stochastic term $I_s(t_k) - I_s(t_{k-1})$:

\begin{equation}
    I_s(t_k) - I_s(t_{k-1}) = \sum_{i=1}^n \biggl( \sigma_i(t_k)
    \int_0^{t_k} e^{-\alpha_i(t_k-u)} dz_i(u) - \sigma_i(t_{k-1})
    \int_0^{t_{k-1}} e^{-\alpha_i(t_{k-1}-u)} dz_i(u) \biggr)
\end{equation}

Defining:

\begin{equation}
    f_i(t) = \int_0^{t} e^{-\alpha_i(t-u)} dz_i(u)
\end{equation}

Substitution this into the above equation:

\begin{equation}
    I_s(t_k) - I_s(t_{k-1}) = \sum_{i=1}^n \biggl( \sigma_i(t_k)
    f_i(t_k) - \sigma_i(t_{k-1}) f_i(t_{k-1}) \biggr)
\end{equation}

When simulating, this expression will be adaped to the filtration $\mathcal{F}_{t_{k-1}}$, hence the
$f_i(t_{k-1})$ will have been realised. $f_i(t_k)$ will be part realised, hence it is instructive
to split this into it's deterministic and stochastic parts, as of $t_{k-1}$. First making the
substituting $t_k = t_{k-1} + t_k - t_{k-1}$:

\begin{eqnarray}
    \nonumber
    f_i(t_k) = e^{-\alpha_i(t_k - t_{k-1})} \int_0^{t_k} e^{-\alpha_i(t_{k-1}-u)} dz_i(u) \\
        = e^{-\alpha_i(t_k - t_{k-1})} \biggl(\int_0^{t_{k-1}} e^{-\alpha_i(t_{k-1}-u)} dz_i(u) +
        \int_{t_{k-1}}^{t_k} e^{-\alpha_i(t_{k-1}-u)} dz_i(u) \biggr)
\end{eqnarray}

Noticing that the first integral is the definition of $f_i(t_{k-1})$, the function $f_i$ can
be defined recursively:

\begin{equation}
    f_i(t_k) = e^{-\alpha_i(t_k - t_{k-1})}f_i(t_{k-1}) + \int_{t_{k-1}}^{t_k} e^{-\alpha_i(t_k-u)} dz_i(u)
\end{equation}

For any $t_k > t_{k-1}$ and base case:

\begin{equation}
    f_i(0) = 0
\end{equation}

In this form $f_i(t)$ can be recognised as an Ornstein–Uhlenbeck process with zero drift,
mean reversion parameter $\alpha_i$, and $\sigma$ (coeffient of Brownian motion) of 1.

\bigskip

When simulating the spot price for an increasing sequence of $n$
future times $t_1, t_2 \hdots t_{n-1}, t_n$ where $0 < t_{k-1} < t_k$, for each of these
times the first step is to calculate $f_i(t_k)$ recursively, using the above relationship % TODO word better (maybe equation ref)
for $i = 1, \hdots, n$.

\begin{equation}
    f_i(t_k) = e^{-\alpha_i(t_k - t_{k-1})}f_i(t_{k-1}) + Z_i(t_k)
\end{equation}

Where, using the property of Ito Integrals, a vector where the i\textsuperscript{th} item is $Z_i(t_k)$ follows a
multivariate normal distribution, with mean zero and covariance between elements:

\begin{equation}
    cov(Z_i(t_k), Z_j(t_k)) = \frac{\rho_{i, j}}{\alpha_i + \alpha_j}(1 -
    e^{-(\alpha_i + \alpha_j)(t_k - t_{k-1})})
\end{equation}

Similar to before, we have a situation where the covariance is not defined for the case
where both $\alpha_i$ and $\alpha_j$ are equal to zero. This case can be allowed, as
before, by redefining $cov(Z_i(t_k), Z_j(t_k))$ to it's continuous extension:

\begin{equation}
    cov(Z_i(t_k), Z_j(t_k)) = \rho_{i, j} \vartheta_{t_k-t_{k-1}, 0}(\alpha_i + \alpha_j)
\end{equation}

\bigskip

The spot price can then be calculated recursively from the values of $f_i(t_k)$ for $k>1$:

\begin{equation}
    \label{eq:appendix_spot_sim}
    S(t_k) = S(t_{k-1}) \frac{F(0, t_k)}{F(0, t_{k-1})} e^{- \frac{1}{2} (V_s(t_k) -
    V_s(t_{k-1})) + \sum_{i=1}^n \bigl(\sigma_i(t_k)f_i(t_k) - \sigma_i(t_{k-1})f_i(t_{k-1})\bigr)}
\end{equation}

With the special case where $k=1$:

\begin{equation}
    S(t_1) = F(0, t_1) e^{- \frac{1}{2} V_s(t_1) +
    \sum_{i=1}^n \sigma_i(t_1) f_i(t_1) }
\end{equation}

\subsection{Multiple Commodities}
For multiple commodities, simulation of $m$ commodity underlying spot prices is
performed for $l \in [1, m]$ using the following:

\begin{equation}
    S^l(t_k) = S^l(t_{k-1}) \frac{F^l(0, t_k)}{F^l(0, t_{k-1})} e^{- \frac{1}{2} (V_s^l(t_k) -
    V_s^l(t_{k-1})) + \sum_{i=1}^{n^l} \bigl(\sigma_i^l(t_k)f_i^l(t_k) - \sigma_i^l(t_{k-1})f_i^l(t_{k-1})\bigr)}
\end{equation}

Where $V_s^l$ is defined as being the same as $V_s$, except with $n$ and all $\alpha$ and
$\sigma$ items being superscripted with $l$. $f_i^l$ is defined recursively as:

\begin{equation}
    f_i^l(t_k) = e^{-\alpha_i^l(t_k - t_{k-1})}f_i^l(t_{k-1}) + Z_i^l(t_k)
\end{equation}

$Z_i^l(t_k)$ is multivariate normally distributed, with mean zero and covariance:

\begin{equation}
    \label{eq:appendix_z_covar}
    cov(Z_i^x(t_k), Z_j^y(t_k)) = \rho_{i, j}^{x, y} \vartheta_{t_k-t_{k-1}, 0}(\alpha_i^x + \alpha_j^y)
\end{equation}

\subsection{Markov Property of Spot Price}

Using the definition of $f_i$, \ref{eq:appendix_spot_sim} can be rewritten as:

% TODO sort out this equation being too big
\begin{equation}
    S(t_k) = S(t_{k-1}) \frac{F(0, t_k)}{F(0, t_{k-1})} e^{- \frac{1}{2} (V_s(t_k) -
    V_s(t_{k-1})) + \sum_{i=1}^n \bigl(\sigma_i(t_{k-1}Z_i(t_k)) + f_i(t_{k-1})
    (\sigma_i(t_k) e^{-\alpha_i (t_k - t_{k-1})} - \sigma_i(t_{k-1}) ) \bigr)}
\end{equation}

All terms in the right hand side of the above equation are deterministic, apart from
$Z_i$, $S(t_{k-1})$ and $f_i(t_{k-1})$, and given knowledge of the filtration
$\mathcal{F}_{t_{k-1}}$ only $Z_i$ is random.

\bigskip
Defining the vectors $\+z$ and $\+f_{t_k}$, both containing $n$ elements, with the $i^{th}$ element
being equal to $Z_i(t_k)$ and $f_i(t_k)$ respectively.

\begin{equation}
    S(t_k) = \omega(\+z, \+f_{t_{k-1}})
\end{equation}

Note that $S(t_{k-1})$ has been omitted from the above, as it itself a deterministic
function of the $f_i$ terms.
Given knowledge of the filtration $\mathcal{F}_{t_{k-1}}$ the expectation of an arbitray
function $g$ can be written as:

\begin{equation}
    \mathbb{E}[g(S(t_k)) | \mathcal{F}_{t_{k-1}}] =
        \int_\mathbb{R} \hdots \int_\mathbb{R} \omega(\+u, \+f_{t_{k-1}})
        h(\+u) du_1 \hdots du_n
\end{equation}
% TODO define u
Where $h$ is the probability density function of the multivariate normal distribution
with covariance given by \ref{eq:appendix_z_covar}.

\bigskip

\begin{equation}
    \mathbb{E}[g(S(t_k)) | \mathcal{F}_{t_{k-1}}] = \mathbb{E}[g(S(t_k)) | \+f_{t_{k-1}}]
\end{equation}

The intuitive meaning of this is that, at any point in time $t$, given knowledge of the
vector of mean reverting factors $\+f_t$, we know the exact distribution of the
spot price for any time greater than $t$.

% TODO significance of F as factor for Markovian

\bibliographystyle{plainnat}
\bibliography{multifactor_price_process}

\end{document}


\section{\textbf{AtomicMRMWRegisterTest}}

\subsection{Particular Case (problem)}
The problem we are trying to solve here, is that of implementing an
atomic multi-valued \footnote{As opposed to boolean values, which have
only a couple of values; while multi-valued can range over a big set,
like integers.}
multiple-reader multiple-writer register. Let us
briefly recall that atomic registers are the most powerful ones, when
compared with the
other two categories: safe and regular. Informally, atomic registers
behave like one would expect when reads overlap writes: the reads
always ``see'' the last written value; while regular registers allows
to see either previous or latest value. Finally ``safe'' registers
allow reads to see any value (not safe at all then!).

\subsection{Solution}
The solution from the book uses as primitive blocks the atomic
multi-valued multi-reader single-writer registers; we build an array of them whose
size equals the number of threads we want to support (assuming number
of writers is same as readers). When a given thread \C{A} wants to
write a value, it needs to read all the values on the array and writes
to its own cell an stamped value that is bigger than any one
observed. When same thread wants to read a value, it reads again whole
array and returns the one with biggest stamped value (resolving ties
with thread ids). This is essentially the same as Lamport's Bakery
algorithm from mutual exclusion chapter; the code is small enough to
fit here, so there it goes for reference: \\

\newpage
\begin{lstlisting}[style=numbers]
public class AtomicMRMWRegister<T> implements Register<T>{
  // array of multi-reader single-writer registers
  private StampedValue<T>[] a_table;
  public AtomicMRMWRegister(int capacity, T init) {
    a_table = (StampedValue<T>[]) new StampedValue[capacity];
    StampedValue<T> value = new StampedValue<T>(init);
    for (int j = 0; j < a_table.length; j++) {
      a_table[j] = value;
    }
  }
  public void write(T value) {
    int me = ThreadID.get();
    StampedValue<T> max = StampedValue.MIN_VALUE;
    for (int i = 0; i < a_table.length; i++) {
      max = StampedValue.max(max, a_table[i]);
    }
    a_table[me] = new StampedValue<T>(max.stamp + 1, value);
  }
  public T read() {
    StampedValue<T> max = StampedValue.MIN_VALUE;
    for (int i = 0; i < a_table.length; i++) {
      max = StampedValue.max(max, a_table[i]);
    }
    return max.value;
  }
}
\end{lstlisting}

\subsection{Experiment Description}
The test program AtomicMRMWRegisterTest includes the following individual
test cases:

\begin{itemize}
  \item \C{testSequential}: calls \C{write} method first with a value
    of 11, then calls \C{read} method expecting read 11. A single
    thread is used (main thread).
  \item \C{testParallel}: calls twice method \C{write}, putting first
    11 then 22 value. Then proceeds to create 8 reader threads, which
    expect all to read 22. This test is not really exercising
    multi-write capability of the register.
    sequentially.
\end{itemize}

\subsection{Observations and Interpretations}
The test performs well on 2 and 24 core machines, without any race
conditions nor abnormal behaviors. This partly because, the test is
not really exercising the multi-write capability, nor the interlacing
of writes and reads. We believe the authors just copied paste a
previous test (probably one that just cared about single reader and
multiple writers), and forgot to update. Due time constraints we did
not modify the test to exercise those missing features; a sample
execution is shown below: \\\\

\begin{verbatim}
$ junit register.AtomicMRMWRegisterTest
.sequential read and write
.parallel read

Time: 0.004

OK (2 tests)
\end{verbatim}
\hfill


\documentclass{article}
%\setkomafont{disposition}{\normalfont\bfseries}

\usepackage{listings}
\usepackage{color}
\usepackage{amsmath}
\usepackage{graphicx}
\usepackage{float}
%\usepackage[toc,page]{appendix}
\usepackage{caption}
\usepackage[margin=1.25in]{geometry}
%\usepackage{apacite}
\usepackage{url}
\usepackage{appendix}
\usepackage{pdfpages}
%\usepackage[demo]{graphicx}
\usepackage{caption}
\usepackage{subcaption}
\usepackage{rotating}
\usepackage{tikz}
\usepackage{hhline}
\usepackage[hidelinks]{hyperref}

\tikzset{%
	block/.style    = {draw, thick, rectangle, minimum height = 3em,
		minimum width = 3em},
	sum/.style      = {draw, circle, node distance = 2cm,fill=blue!20}, % Adder
	input/.style    = {coordinate}, % Input
	output/.style   = {coordinate} % Output
}
% Defining string as labels of certain blocks.
\newcommand{\suma}{\Large$+$}
\newcommand{\inte}{$\displaystyle \int$}
\newcommand{\derv}{\huge$\frac{d}{dt}$}

\usepackage{fancyhdr}
\pagestyle{fancy}
\fancyhf{}
\lhead{2127147}
\rhead{Subtractive Synth}
\rfoot{Page \thepage}

\title{\textbf{A Subtractive Synthesiser \\ using C++, Python \& SWIG\\
\large Audio Programming and Signal Processing 4 }}

\date{}
\author{Jamie Brown}

\begin{document}
	\vspace{100mm}
	\maketitle
	\thispagestyle{fancy}
	\pagenumbering{arabic}
\centering
\begin{abstract}
	Realtime audio synthesis requires fast computations in order to provide low latency for the user. Using a modular, object orientated approach, a subtractive synthesizer has been designed using the Python alongside a C++ module that has been interfaced using SWIG.
\end{abstract}
\vspace{2cm}
\includegraphics[width=0.4\linewidth]{window.png}
\pagebreak
\flushleft
\section{Introduction}
As this program is rather complex, it's useful to develop an abstracted, modular design considering the roles of desired modules (classes). What is required in order to develop a functioning software synthesiser?

\begin{enumerate}
	\item A source of synthesised sound (additive, subtractive, stochatic etc.)
	\item An audio buffer
	\item A graphical interface for the user
	\item A module to handle incoming MIDI events
	\item A module to route the input data from the GUI and MIDI
\end{enumerate}
A modular design really necessates an object oriented approach so we'll use Python to develop points two to five as we can use pyQtMultimedia, pyQtWidgets and mido  to make the programming easier than C++. Point one (sound source) is a little trickier as this is going to require speed, we'll use C++ to code this.
\section{Resonator}
One way to synthesise a tone is using subtractive synthesis.
This usually involves generating noise and band pass filtering around the centre frequency to generate the tone.
A common method of doing this is by using a second order infinite impulse response filter (IIR).
Firstly, let's look at the transfer function for a resonator with a centre frequncy around $f_0$ in the Z domain:
\begin{equation}
H(Z)=\frac{1}{1-2rcos\theta Z^{-1}+r^2Z^{-2}}
\end{equation}
From this we can derive a data flow diagram. We don't need to use a standard biquad form as the feed-forward coefficiant(the numerator) in this case is 1  so the output of the filter is simply the output of the first summing junction. A larger $r$, as we approach the edge of the unit circle, will result in a narrower, taller pass band due to the longer impulse response. This would result in a less noisy, more defined sounding tone as the pass band draws in around the centre frequency. We're going to design our resonator to have a variable r, by varying the \textit{quality-factor}.

\tikzstyle{block} = [draw,fill=blue!20,minimum size=2em]
% diameter of semicircle used to indicate that two lines are not connected
\def\radius{.7mm}
\tikzstyle{branch}=[fill,shape=circle,minimum size=3pt,inner sep=0pt]
\begin{figure}[H]
	\begin{tikzpicture}[node distance=2cm>=latex',scale=1.5]

	\node[sum] at (3,-1) (block1) {$\Sigma$};
	\node[block][text width=1.75cm,align=center] at (5,-2.85) (cos) {$2rcos(\frac{2\pi f_0}{f_s})$};
	\node[block][text width=1.5cm,align=center] at (5,-4) (r) {$-r^2$};
	\node[block] at (6.5,-2.25) (z1) {$Z^{-1}$};
	\node[block] at (6.5,-3.5) (z2) {$Z^{-1}$};
	\node[input] at (2,-2) (block11) {ADC$_channel1$};
	%\node[block][text width=1.5cm,align=center] at (6.5,-1) (block5) {$F_{static}$};
%	\node[block] at (8.25,-4.5) (block8) {$\frac{1}{t_{s}}$};
%	\node[sum] at (8.25,-1) (block6) {$\Sigma$};
%	\node[sum] at (6.75,-4.5) (block9) {$\Sigma$};
%	\node[block] at (6.025,-3.125) (block10) {$-2$};
%	\node at (2,-2.75) (input2) {ADC$_2$};
	\node at (1,-1) (input1) {$x(n)$};
	\node at (9,-1) (input3) {$y(n)$};

	\draw[->] (input1) -- (block1);
	\draw[->] (block1) -- (input3);
	\draw[->] (r) -| (block1);
	\draw[-] (cos) -- (3.75,-2.85);
	\draw[->] (3.75,-2.85) --(block1);
	\draw[->] (6.5,-1) -- (z1);
	\draw[->] (z1) -- (z2);
	\draw[->] (6.5,-2.85) -- (cos);
	\draw[->] (z2) |- (r);

	\end{tikzpicture}
	\caption{Resonator Data Flow Diagram}
\end{figure}

\pagebreak
\subsection{C++}
The resonator module has one method \textit{filter{}}. It's sole purpose is to generate one sample from a random floating point and is designed to take in a value for the centre frequency, the desired quality factor (Q) and the sampling frequency. It has to know what the sampling rate is because the frequency needs to be normalised before the module can correctly calculate the first coefficients. The following equation is used to evaluate r in relation to the Q-factor:
\begin{equation}
r=1-sin({\frac{\omega_0}{Q}})
\end{equation}
We now need two buffers, one for each delay step, to store the previous samples to complete the computation. These need to be initialised in the constructor as we don't want them to be overwritten every time the \textit{filter{}} method gets called as that would defeat the purpose.
\begin{figure}[H]

\begin{lstlisting}[language=C++]
Resonator::Resonator(float f, float q, int SAMPLE_RATE) :
w(2*atan(1)*4*(f/SAMPLE_RATE)),r(1-sin(w/q)),a1(-2*r*cos(w))
,a2(pow(r,2)),buffer1(0),buffer2(0),x(f)
{
}

\end{lstlisting}
\caption{Resonator.cxx constructor}
\end{figure}

The \textit{filter()} method is an exact implementation of the data flow diagram seen in figure 1. We start by generating a random floating point between 0 and 1, equivalent to $x(n)$. The summing junction is equivalent to `acc\_input' which is written to `buffer1' after computation. Each value is shifted along to the next buffer to store them for when the method is next called, this is equivalent to the two delay blocks in figure 1. The returned value `acc\_input' is equivalent to y(n).
\begin{figure}[H]
	\begin{lstlisting}[language=C++]
float Resonator::filter(){
	float v=static_cast <float> (rand())/static_cast <float> (RAND_MAX);
	float acc_input=v-buffer1*a1-buffer2*a2;
	buffer2=buffer1;
	buffer1=acc_input;
	return acc_input;
}
	\end{lstlisting}
	\caption{Resonator.cxx filter() method}
\end{figure}
All constructor variables and methods are initialised in the header file which is included in the appendix.
\subsection{Generating the Python Module}
The differences between the two languages are numerous, most notably related to memory allocation and types. To generate a resonator module in Python we can use the Simple Wrapper Interface Generator (SWIG) to generate wrapper code that can be linked to the C++ object files. However, there are a few things that need to be taken care of first.
\subsubsection{Interface File}
An interface file needs to be made in order to parse the appropriate files to SWIG and let it know what module needs to be made. In this case the interface file is very simple:
\begin{figure}[H]
	\begin{lstlisting}[language=c]
%module Resonator

%{
#define SWIG_FILE_WITH_INIT
#include "Resonator.h"
%}

%include "Resonator.h"

	\end{lstlisting}
	\caption{Interface file for the resonator: \textit{Resonator.i}}
\end{figure}
\subsubsection{makefile}
Now that an interface file has been created, it's time to actually compile the C++ program! The easiest way to do this and minimise frustration during future debugging is to write a make file that compiles the necessary files and also assigns dependicies. This means that if a file, such as the header file, is altered then when \textbf{make} is executed, only the necessary files are rebuilt. This example line of code from my makefile shows that the target object file (Resonator.o) is dependent on the C++ file (Resonator.cxx), if I don't modify Resonator.cxx then \textbf{make} won't bother executing the system command on the second line because it doesn't need to:
\begin{figure}[H]
\begin{lstlisting}[language=make]
Resonator.o: Resonator.cxx
	g++ -fPIC -c Resonator.cxx
\end{lstlisting}
\caption{An example of a dependancy in the makefile}
\end{figure}
Another really handy use of the makefile for this program is that the command to generate the wrapper code from SWIG can be executed in the file itself. In this case, the target is the python file and it's dependancy is the interface file. The entire makefile is included in the appendix.
\begin{figure}[H]
	\begin{lstlisting}[language=make]
Resonator.py: Resonator.i
	swig -c++ -python Resonator.i
	\end{lstlisting}
	\caption{Using SWIG to generate wrapper code in a makefile}
\end{figure}

Implementing our resonator in Python is as simple as importing any other shared object. I have imported it as \textbf{ResC} simply because I made a prototype resonator in Python for testing/debugging purposes, under the same name, so it is helpful to make it very clear that this module is the C++ version.
 \begin{figure}[H]
 	\begin{lstlisting}[language=python]
import Resonator as ResC
 	\end{lstlisting}
 	\caption{Importing a shared object into Python}
 	\end{figure}

\section{The Generator Object}
\subsection{Audio Buffers}
A \textbf{Generator} object is used to call instances of the resonator and handle the synthesised audio in managable amounts of samples. It handles the resonator audio by supplying a chunk size of audio, `NO\_OF\_SAMPLES', which is the length of the buffer. The Generator is a subclass of the QIODevice module, this means that it inherits all the same attributes and methods as a QIODevice.

 \begin{figure}[H]
	\begin{lstlisting}[language=python]
class Generator(QIODevice):
SAMPLES_PER_READ=1024
def __init__(self,format,parent=None):
	self.format=format
	QIODevice.__init__(self,parent)
	self.data=QByteArray()
	\end{lstlisting}
	\caption{The generator constructor}
\end{figure}

The QIODevice needs a method \textit{start()} which has an attribute \textit{open()}. This simply indicates that the Generator is ready upon instantiation and is set as read-only:

 \begin{figure}[H]
	\begin{lstlisting}[language=python]
    def start(self):
		self.open(QIODevice.ReadOnly)

	\end{lstlisting}
	\caption{The \textit{start()} method}
\end{figure}
\subsection{Using the Resonator}
We want to create an instance of a Resonator when a new note is pressed. This can be done using a pyqtslot that passes a value when a `note-on' MIDI message is received, this is expained in further detail later. An incoming MIDI note value is converted to the desired frequency and passed to the new instance of the resonator:
 \begin{figure}[H]
	\begin{lstlisting}[language=python]
	@pyqtSlot(int)
	def noteOn(self,d):
		self.state=1
		f=(2**((d-69)/12))*440
		self.resonator=ResC.Resonator(f,self.q,SAMPLE_RATE)
	\end{lstlisting}
	\caption{pyqtSlot for generator when a `note\_on' message is received}
\end{figure}
\pagebreak
The audio is generated using the \textit{generate()} method. It creates an array with number of elements equal to the specified chunk size and writes samples to each entry by calling the resonator's \textit{filter()} method. The array is multiplied by a velocity scaling factor, volume scaling factor and on/off state. It is converted from floating point to 16-bit integer arithmetic for the QIODevice:
 \begin{figure}[H]
	\begin{lstlisting}[language=python]
    def generate(self,NO_OF_SAMPLES):
		tone=np.zeros(NO_OF_SAMPLES)
		for i in range(len(tone)):
			tone[i]=self.resonator.filter()
		tone=(self.vel*50*tone*self.state*self.vol).astype(np.int16)
	return tone.tostring()
	\end{lstlisting}
	\caption{The \textit{generate()} method}
\end{figure}
\subsection{How does Qt know when to read?}
A \textit{readData()} method has to be included so that Qt's executive reads samples to the output stream at the correct point depending on the specified chunk size:
 \begin{figure}[H]
	\begin{lstlisting}[language=python]
    def readData(self,bytes):
		if bytes>2*Generator.SAMPLES_PER_READ:
			bytes=2*Generator.SAMPLES_PER_READ
		return self.generate(bytes//2)
	\end{lstlisting}
	\caption{The \textit{readData()} method}
\end{figure}

\pagebreak
\section{MIDI}
A synthesiser is no use unless you can play it with a keyboard! Well that's not strictly true, you can play them with knobs, potentiometers, patch cables etc...but that doesn't change the fact that these signals have to digitally interfaced somehow and the defacto standard is MIDI.

\medskip I'm going to make an object that reads the MIDI ports and sends the appropriate messages depending on how a note is pressed. Firstly, we need a bit of backend software to get the MIDI up and running.
\subsection{Rtmidi}
This MIDI backend is ideal because it's so widely used. Another advantage is that virtual ports can be created so that MIDI messages can be passed across threads, this will come in very useful later. This could also be very useful if you wanted to control some outboard hardware by outputting MIDI for instance. The following example uses the ALSA API as I'm running this on a LINUX machine.

 \begin{figure}[H]
	\begin{lstlisting}[language=python]
	def __init__(self):
		QObject.__init__(self)
		mido.set_backend(
		 'mido.backends.rtmidi/LINUX_ALSA'
		  )
	\end{lstlisting}
	\caption{Configuring the MIDI backend}
\end{figure}
\subsection{mido}
\textbf{mido} is an easy to use library of Python objects for MIDI programming. Using the following code, MIDI messages can be read and emitted to pyqt signals. A writeable MIDI client will be created under ALSA which we can use to connect a hardware controller of our choice. I've chosen to print out messages that I thought would be of use in testing the ports: the velocity of each note and whether it was a \textit{note-on} or \textit{note off}.
 \begin{figure}[H]
	\begin{lstlisting}[language=python]
	with mido.open_input(
		'pipes',
		virtual=True
		) as mip:
		for mmsg in mip:
			print(mmsg.type)
			print(mmsg.velocity)
	\end{lstlisting}
	\caption{Opening virtual ports and printing MIDI messages}
\end{figure}

\pagebreak
\subsection{MIDI Messages \& Routing}
With this we can generate signals for other modules or threads in the program in order to control certain parameters. I'm mostly interested in three of these: \textit{note-on}, \textit{note-off} and \textit{velocity}. In most conventional applications, the instrument should , to some extent, stop making a sound after the keys are released. We therefore need to send two signals to deal with this, I'll generate these based on the note's state using a standard \textit{if/else} clause. I'll also emit a signal containing the note's velocity:

 \begin{figure}[H]
	\begin{lstlisting}[language=python]
	if mmsg.type==`note_on':
		self.noteOn.emit(mmsg.note)
	elif mmsg.type==`note_off':
		self.noteOff.emit(mmsg.note)
	self.noteVelocity.emit(mmsg.velocity)
	\end{lstlisting}
	\caption{Emitting MIDI messages through virtual ports}
\end{figure}

Lastly, the ports need to be initialised as methods:
 \begin{figure}[H]
	\begin{lstlisting}[language=python]
	class MidiPortReader(QObject):
		noteOn=pyqtSignal(int)
		noteVelocity=pyqtSignal(int)
		noteOff=pyqtSignal(int)
	\end{lstlisting}
	\caption{Initialising virtual MIDI ports}
\end{figure}
These are now ready to be received as slots in other threads. It's worth bearing in mind that not all MIDI keyboards will send the same MIDI messages; many will in fact not send a \textit{note-off} and instead will send a second \textit{note-on} with a velocity of zero. I've accounted for this as each buffer gets multiplied by the velocity which is a float scaled from zero to one.

\pagebreak
\section{GUI}
As stated in the introduction, we need a user interface for the instrument so that `uncomputery' folk can use it. As much as I'd delight in programming a command line driven UI for the synthesiser, it isn't exactly commercially viable or useful to most musicians. Alas, I have devised a somewhat minimalist GUI using QtGui and QtWidgets.
\subsection{Making the Clicky Things}
Buttons, sliders and labels like most things, have to be initialised to bring them into existence. Most of these objects have attributes that you can use to modify to get it looking how you want or outputting a certain scale of data. This is all done in a method called \textit{create\_UI} the  purpose of which is somewhat self-explanatory. The following few lines of code set up the volume slider and its corresponding label. The \textit{volumeSlider} is prefaced with \textit{self} because we're going to use it to send volume data through a virtual port:
 \begin{figure}[H]
	\begin{lstlisting}[language=python]
	volLabel=QLabel()
	volLabel.setText("Volume")
	self.volumeSlider=QSlider(Qt.Horizontal)
	#SET SLIDER SCALE 0-100
	self.volumeSlider.setMinimum(0)
	self.volumeSlider.setMaximum(100))
	\end{lstlisting}
	\caption{Initialising the volume slider}

\end{figure}
\subsection{The Window Layout}
A total vertical layout is made alongside several horizontal layouts containing the sliders and their labels. These horizontal layouts are  arranged to fit into the overall vertical layout one by one. Here is an example of setting the vertical layout and superimposing the layout containing the Q-factor slider:
 \begin{figure}[H]
	\begin{lstlisting}[language=python]
	vLayout=QVBoxLayout(self)
	h2Layout=QHBoxLayout()
	h2Layout.addWidget(qfacLabel)
	h2Layout.addStretch(1)
	h2Layout.addWidget(self.qfacSlider)
	\end{lstlisting}
	\caption{Initialising the volume slider}

\end{figure}
\pagebreak
\subsection{Quit Button}
The quit button is set to terminate the program when clicked by connecting it to its attribute \textit{quitClicked} using the following line of code in the \textit{create\_UI()} method:
 \begin{figure}[H]
	\begin{lstlisting}[language=python]
       self.quitButton.clicked.connect(
       self.quitClicked
	)
	\end{lstlisting}
	\caption{Connecting the quit button}

\end{figure}

\subsection{Embedded Image}
Raster images of type .jpg or .png can be implemented in the GUI using \textit{QPixmap()}. I put a picture of David Lynch playing a synthesiser in the main window because David Lynch is cool.

 \begin{figure}[H]
	\begin{lstlisting}[language=python]
	    pixmap=QPixmap()
	    pixmap.load('lynch2.jpeg')
	    pixmap=pixmap.scaledToWidth(200)
	    self.lynch.setPixmap(pixmap)
	\end{lstlisting}
	\caption{Embedding a photograph of critically acclaimed filmmaker and musician David Lynch playing a synthesiser onto the GUI}

\end{figure}
 \pagebreak

\section{The Window Object}
This class contains the audio formatting, thread connections and GUI method. In a sense this is the central interface for all the modules of our synthesiser.

\subsection{Audio Formatting}
Standard audio formatting parameters are set in the constructor such as sample rate, audio codec, number of channel etc. This is easy to implement as \textit{Window} is a subclass of QtWidget:
 \begin{figure}[H]
	\begin{lstlisting}[language=python]
	format=QAudioFormat()
	format.setChannelCount(AUDIO_CHANS)
	format.setSampleRate(SAMPLE_RATE)
	format.setSampleSize(SAMPLE_SIZE)
	format.setCodec("audio/pcm")
	format.setByteOrder(
	QAudioFormat.LittleEndian
	)
	format.setSampleType(
	QAudioFormat.SignedInt
	)
	\end{lstlisting}
	\caption{Formatting the audio}

\end{figure}

It's also important to let Qt know the chunk/buffer size and to output the audio via it's executive:

\begin{figure}[H]
	\begin{lstlisting}[language=python]
	self.output=QAudioOutput(format,self)
	output_buffer_size=\
	int(2*SAMPLE_RATE \
	*CTRL_INTERVAL/1000)
	self.output.setBufferSize(
	output_buffer_size
	)
	\end{lstlisting}
	\caption{Setting the chunk size}

\end{figure}

\pagebreak
\subsection{Connecting it all Together}
Last, but not least, all the virtual cables have to be slotted together. Qt's aptly named \textit{signals and slots} allow us to do this rather seamlessly. I've already demonstrated several of these signals during the MIDI section. All that's left is to connect them in
the \textit{Window} constructor. Firstly we'll start a MIDI thread:

 \begin{figure}[H]
	\begin{lstlisting}[language=python]
	self.midiListener=MidiPortReader()
	self.listenerThread=QThread()
	self.midiListener.moveToThread(
		self.listenerThread
	)

	self.listenerThread.started.connect(
		self.midiListener.listener
	)

	self.listenerThread.start()
	\end{lstlisting}
	\caption{Starting a MIDI Thread}

\end{figure}
We'll now connect all the appropriate midi ports together along with the values from the sliders:
 \begin{figure}[H]
	\begin{lstlisting}[language=python]
        self.midiListener.noteOff.connect(self.geerator.noteOff)
        self.midiListener.noteVelocity.connect(self.generator.noteVelocity)
        self.midiListener.noteOn.connect(self.generator.noteOn)
        self.volumeSlider.valueChanged.connect(self.generator.volSlide)
        self.qfacSlider.valueChanged.connect(self.generator.qFactor)
	\end{lstlisting}
	\caption{Connecting ports}
\end{figure}
Lastly, all that has to be done is to make an instance of a generator in the constructor:

We'll now connect all the appropriate midi ports together along with the values from the sliders:
\begin{figure}[H]
\begin{lstlisting}[language=python]
	self.generator=Generator(format,self)
\end{lstlisting}
\caption{An instance of a generator}
\end{figure}

\pagebreak
\section{Conclusion}
The synthesiser works as expected. When run from the command line in Python3, the GUI appears and after connecting the MIDI controller to the open rtmidi client using qjackctl, the player can play the synthesiser and vary the volume and q-factor of the resonator. There are however various imporovements that could be made.

\medskip Most notable of which is the lack of polyphony, I attempted this by creating a list of voices with each entry being used to initilise a resonator however this proved to be inefficient so I unfortunately abandoned the idea. I believe that implementing polyphony effectively would most likely involve a slight redesign of the C++, perhaps having \textit{ResC} deal with larger chunks of audio rather than one sample.

\medskip In addition to this, I have compiled a short list of possible improvements that could be made:

\begin{enumerate}
	\item Implement polyphony
	\item Implement trapezoidal enveloping to deal with the `clicks' that occur during a \textit{note-off} phase
	\item Implement a low frequency oscillator
	\item Refine the modularity of design
	\item Implement compatibility more unconventional MIDI controller (Akai MPC, Novation Launchpad etc.)
\end{enumerate}

\pagebreak
\appendix
\section{synth.py}
\lstinputlisting{synth.py}
\pagebreak
\section{Resonator.h}
\lstinputlisting{Resonator.h}
\section{Resonator.cxx}
\lstinputlisting{Resonator.cxx}
\pagebreak
\section{Resonator.i}
\lstinputlisting{Resonator.i}
\section{makefile}
\lstinputlisting{makefile}
\end{document}


% !TEX root =main.tex
\section{Survey of Related Work}\label{Survey-of-Related-Work}
\subsection{Time-lock Puzzles}

The idea to send information into the \emph{future}, i.e.
time-lock puzzle/encryption, was first put forth by Timothy C. May. A time-lock puzzle allows a party to encrypt a message such that it cannot be decrypted  until a certain amount of time has passed. In general,  a  time-lock scheme should allow    generating (and verifying) a puzzle to take less time than solving it. The time-lock puzzle scheme that May proposed lies on a trusted agent. Later on, Rivest \textit{et al} \cite{Rivest:1996:TPT:888615} propose a protocol that does not require a trusted agent and is secure against a receiver
who may have access to many  computation resources that can be run in parallel. It is based on Blum-Blum-Shub pseudorandom number generator that relies on modular repeated squaring, believed to be sequential. The scheme in \cite{Rivest:1996:TPT:888615} allows (only) the puzzle creator to  verify the correctness of the puzzle solution using a secret key and the original secret message.  This scheme has been the core of (almost) all later time-lock puzzles schemes that supports the encapsulation of an arbitrary message. Later on, \cite{BonehN00,DBLP:conf/fc/GarayJ02} proposed timed commitment schemes that offer more security properties, in the sense that they   allow a puzzle generator to prove (in Zero-knowledge) to a puzzle solver that the correct solution (e.g. a signature of a public document) will be recovered after a certain time before the solver starts solving the puzzle. These schemes are more complex, due to the use of zero-knowledge proofs, and less efficient than \cite{Rivest:1996:TPT:888615}.    Very recently, \cite{MalavoltaT19,BrakerskiDGM19}  propose protocols for homomorphic time-lock puzzles, where an arbitrary function can be run over puzzles before they are solved. They mainly use  fully homomorphic encryption and   the RSA puzzle, proposed in \cite{BrakerskiDGM19}, in a nutshell. In these protocols, all puzzles have an identical time parameter, and their solutions are supposed to be discovered at the same time. The main difference between the two protocols is the security assumption they rely on (i.e. the former uses a non-standard assumption while the latter relies on a standard one). Since both schemes use a generic fully homomorphic encryption, it is not hard to make them publicly verifiable. However, they  are only of theoretical interest as in practice they impose  high computation and communication costs, due to the use of fully homomorphic encryptions.

%Furthermore, \cite{KarameC10} proposes a privately verifiable puzzle scheme that has up to $12\times$  lower cost than \cite{Rivest:1996:TPT:888615} in puzzle generation and verification phases. However,  it relies on  a new and non-standard assumption (i.e. computationally infeasible to compute a small private exponent when a public exponent is much larger than the RSA modulus).

We also cover two related but different notions, pricing puzzles, and verifiable delay functions.

\noindent\textbf{\textit{Pricing Puzzles.}} Also known as \emph{client puzzles}. It was first put forth by Dwork \textit{et al.} \cite{DworkN92} who defined it as a function that requires a certain amount of computation resources to solve a puzzle.  In general, the pricing puzzles are based on either hash inversion problems or number-theoretic. In the former category,
a puzzle generator  generates a puzzle as: $h= \mathtt{H}(m||r)$, where $\mathtt{H}$ is a hash function, $m$ is a public value and $r$ is a random value of a fixed size. Given $h, \mathtt{H}$ and $m$, the solver must find $r$ such that the above equation holds. The size of $r$ is picked in such a way that the expected time to find the solution is fixed (however it does not rule out finding the solution on the first attempt). The above hash-based scheme allows a solver to find a solution faster if it has more computational power resources  running in parallel. The application area of such a puzzle includes  defending against denial-of-service (DoS)  attacks, reaching a consensus in cryptocurrencies, etc. A  variant  of such a puzzle uses iterative hashing; for instance, to generate a set of puzzles  in the case where the solver receives a service proportional to the number of puzzles it solves \cite{groza2006chained},  or to generate password puzzle to mitigate DoS attacks \cite{Ma05}. However, the iterative hashing schemes are partially parallelizable, in the sense that every single invocation of the hash function can be run in parallel. Later on,  \cite{MahmoodyMV11} investigates the possibility of constructing (time-lock) puzzles in the random oracle model.  Their main result was negative, that rules out time-lock puzzles that require more parallel time to solve than the total work required to generate.  Also \cite{MahmoodyMV11} proposes an iterative hash-based mechanism (very similar to \cite{Ma05}) that allows a puzzle generator to generate a puzzle with $n$ parallel queries to the random oracle, but the solver needs $n$ rounds of serial queries. Nevertheless, this scheme is also partially parallelizable, as each instance of the puzzle can be solved in parallel. Note that the above hash-based puzzle schemes would have very limited applications if they are used directly to  encapsulate a message: $m'$ of arbitrary size. The reason is that, in these schemes,  the solution  size: $|r|$ plays a vital role in (adjusting) the  time taken to solve the puzzle. If the solution size becomes bigger, as a result of combining $r$ with $m'$, i.e. $r \odot m'$, then it would take longer to find the solution. This means  the puzzles can be used only in the cases where  the time required to find a solution is long enough, and is a function of $|r \odot m'|$, which seriously restricts its application. Researchers also propose non-parallelizable pricing puzzles based on number theoretic \cite{WatersJHF04,KuppusamyRSBN12,KarameC10} whose main application is to resist DoS attacks. These schemes  have a more efficient verification mechanism than the one proposed in \cite{Rivest:1996:TPT:888615}. But, they are only privately verifiable and not designed to encapsulate an arbitrary message.

\noindent\textbf{\textit{Verifiable Delay Function (VDF).}} Allows a prover to provide a publicly verifiable proof stating  it has performed  a pre-determined number of sequential computations. It has many applications, e.g. in decentralised systems to extract  trustworthy public randomness from a blockchain. VDF was first formalised by Boneh \textit{et al} in \cite{BonehBBF18} who proposed several VDF constructions based on SNARKs along with either  incrementally verifiable computation or injective polynomials, or based on time-lock puzzles, where  the SNARKs based approaches require a trusted setup.  Later on,  \cite{Wesolowski19} improved the previous VDF's  from different perspectives and proposed a scheme  based on RSA time-lock encryption, in the random oracle model. To date, this protocol is the most efficient VDF.  It also supports batch verification, such that given a single proof a verifier can efficiently check the validity of multiple outputs of the verifiable delay function. As discussed above, (most of) VDF schemes are built  upon time-lock puzzles, however the converse is not necessarily the case, as VDF's are not designed to encapsulate an  arbitrary private message, and they take a public message as input while time-lock puzzles are designed to conceal a private input message.

\subsection{Proof of Storage}\label{related-work-PoR}

\subsubsection{Traditional Proof of Storage}

Proof of storage (PoS) is a cryptographic protocol that allows a client to  efficiently verify the integrity or availability of its  data stored in a remote server, not necessarily trusted \cite{DBLP:conf/cai/Kamara13}. PoS  can be categorised into two broad classes:   Proofs of Retrievability (PoR) and Proofs of Data Possession (PDP). The main difference between the two categories is the level of security assurance provided. PoR schemes guarantee that the server maintains knowledge of \emph{all} of the client's outsourced data, while  PDP protocols only ensure that the server is storing \emph{most} of the client data. From a technical point of view,  the main difference in most prior PDP and PoR constructions is that PoR schemes store a redundant encoding of the client data on the server by employing an error-correcting code, e.g. Reed-Solomon codes, while such encoding is not utilised in  PDP schemes. Hence, PoR schemes provide stronger security guarantees compared to PDP at the  cost of additional storage space and encoding/decoding, (for more details see \cite{kupcu2010efficient,DBLP:conf/ccs/ShiSP13,Cash:2017:DPR:3038037.3038087}). Furthermore, each PoR and PDP scheme can be also grouped into two categories; namely, publicly and privately verifiable. In a publicly verifiable scheme, everyone without knowing a secret can verify  proof, whereas a verifier in a privately verifiable scheme requires the knowledge of a secret.
%As highlighted in \cite{kupcu2010efficient,DBLP:conf/ccs/ShiSP13,Cash:2017:DPR:3038037.3038087}, the main difference between PoR and PDP is the level of the security they achieve;

The notion of PoR first was introduced and defined in \cite{DBLP:conf/ccs/JuelsK07}, where the authors designed a protocol that utilises  random sentinels, symmetric key encryption,  error-correcting code, and pseudorandom permutation. In this protocol, a client in the setup phase, applies error-correcting code to every file block and encrypts each encoded block. Then, it computes a set of random sentinels and appends them to the encrypted file. It  permutes all values (i.e. sentinels and encrypted file blocks) and sends them to the cloud  server.  To check if  the server has retained the file, the client specifies  random positions of some sentinels in the encoded file and asks
the server to return those sentinel values. Next, the client checks if it gets the sentinels it asked for. In this scheme, the security holds, as the server cannot feasibly distinguish between sentinels and the actual file blocks and the sentinels have been distributed uniformly among the file blocks. But, as individual sentinel is only one-time verifiable, there is an upper bound on the number of verifications performed by the client, and when reached, the client has to re-encode the file.  To overcome the issues related to the bounded number of verifications, the authors have also suggested that sentinels can be replaced with  MAC on every file block or a Merkle tree constructed on the file blocks. This protocol is computationally efficient and its communication cost is linear with the number of challenges sent\footnote{It is not hard to make the communication cost of this scheme constant; for instance, by letting the server order the challenged sentinels, concatenate them and send a hash of the concatenated value to the client.}. The sentinel and MAC-based schemes above are privately verifiable while the one uses a Merkle tree supports public verifiability. However, the publicly verifiable Merkle tree-based approach has a communication cost logarithmic with the file size and the prover has to send a set of file blocks to the verifier that yields a high communication cost.

Later on, \cite{DBLP:conf/asiacrypt/ShachamW08} improves the previous sentinel-based scheme and definition, and proposes two PoR protocols (with an unlimited number of verifications), one utilises  MAC and the other one relies on BLS signatures. In particular, a client at setup phase, encodes its file blocks using error-correcting code and then for each encoded file block it generates a  tag that can be either a MAC or BLS signature of that block. In the verification phase, it specifies a set of random indices corresponding to the file's blocks; and accordingly the server sends a proof to it. These two  schemes have a low communication cost, as due   to the homomorphic property of the tags,  the prover can aggregate  proofs  into a single authenticator value and no file blocks  are sent to the prover. Also, the protocol based on MAC supports efficient private verification. But, the one that uses BLS signatures supports public verifiability at the cost of public key operations and it is far less efficient than the MAC-based one. Within the  last decade, researchers have extended PoR protocols from several perspectives, e.g. those that support:  efficient update \cite{DBLP:conf/ccs/ShiSP13}, the delegation of file pre-processing \cite{ArmknechtBBK16}, or the delegation of verification \cite{armknecht2014outsourced}.

On the other hand, PDP was first introduced in \cite{DBLP:conf/ccs/AtenieseBCHKPS07}. PDP protocols focus only on verifying the  integrity of outsourced data. In this setting,  clients can ensure that a certain percentage of data blocks are available. The authors in \cite{DBLP:conf/ccs/AtenieseBCHKPS07} propose two schemes, for public and private verification both of which utilise RSA-based homomorphic verifiable tags  generated for each file block and use the spot-checking techniques (similar to \cite{DBLP:conf/asiacrypt/ShachamW08}) to check a random subset of a file's blocks. In both schemes, the proof size is constant, while the verification cost is high as it requires  many  exponentiations over an RSA ring. Later on, an  efficient and scalable  PDP scheme that supports a limited number of verifications is proposed in \cite{AteniesePMT08}. The scheme supports only privately verifiable PDP and is based on a combination of pre-computation technique and symmetric key primitives.  Ever since, researcher proposed different variants of PDP, e.g.  dynamic PDP \cite{ErwayKPT09}, multi-replica PDP\cite{DistributedPDP}, keyword-based PDP \cite{SenguptaR18}.

\
Thus,  (a) in publicly verifiable PoS it is assumed the verifier is fully trusted with the verification correctness, (b) these schemes either have a very high verification cost when the proof size is constant (when signature-based tags are used) or have a communication cost logarithmic with the entire file size if their verification is efficient (when a Merkle tree is utilised),  and (c) the privately verifiable proofs can have a constant proof size and efficient verification algorithm, but the data owner has to perform the verification.

\subsubsection {Outsourced PoR}\label{Outsourced-PoS}

Recently,  \cite{armknecht2014outsourced,xu2016lightweight} propose \emph{outsourced} PoR protocols that allow  clients to outsource the   verification to a third party auditor not necessarily  trusted. The scheme in \cite{armknecht2014outsourced} uses MAC-based tags, zero-knowledge proofs, and error-correcting codes. At a high level, the protocol works as follows. At the setup,   the client  encodes its data using error-correcting codes, generates MAC on every file block, and stores the encoded file and tags on the server.  Then, the auditor downloads the encoded file, generates another set of MAC's on the file blocks. It uploads the MAC's to the cloud. Also, the auditor proves to the client in zero-knowledge that it has created each MAC correctly. To do that, it uses a non-interactive zero-knowledge proof in the random oracle model. If the client accepts all zero-knowledge proofs, it sings every proof and sends the signatures back to the auditor. In the verification phase, the auditor sends two sets of random challenges extracted from a blockchain. Upon receiving the challenges, the server provides two separate proofs, one for the auditor and the other one for the client. The auditor verifies the proof generated for it and  locally stores the clients' proofs. In the case where the auditor's proof is not accepted, an honest auditor would inform the client who will come online and checks both its proofs and the auditors' proof. The scheme provides two layers of verification to the client: \textit{CheckLog} and \textit{ProveLog}.  \textit{CheckLog}  is more efficient than the other one, as the auditor sends  much fewer challenges to the server to generate the client's proof for each verification. In the case where the client's check fails, the client will assume that either the server or auditor has acted maliciously, and to pinpoint the malicious party, it needs to proceed to \textit{ProveLog} where allows the client to audit the auditor. In this verification, the auditor must reveal its secret keys with which the client checks all the proofs provided by the server to the auditor for the entire period that the client was offline. In this protocol, the verification phase is efficient (due to the use of MACs). In particular, the verification's computation cost for the auditor and client is linear with the number of challenges and their communication cost is constant in the file size.

Although the protocol in  \cite{armknecht2014outsourced}  is appealing, it has  several shortcomings: (a) auditor can get a free ride: in the case where a known highly reputable  server, e.g. Google or Amazon, always generates   accepting proofs for both client and auditor, an economically rational auditor can skip performing its part (e.g. to save computation cost) and get still paid by the client. This deviation from the protocol can never be detected by the client in the protocol.  (b) no guarantee for a real-time detection/notification: the client may not be notified in the real-time about the data unavailability if the auditor is malicious; therefore, this scheme is not suitable for the case where a client's involvement for the data extraction is  immediately needed once a misbehaviour is detected, e.g., in the case of hardware depreciation. (c) a high cost of auditor onboarding:  revoking an auditor and onboarding a new one, imposes a high cost on the client and new auditor, as new auditor need to re-run the setup phase (that includes data downloading, zero-knowledge proofs) and the client needs to verify and sign the zero-knowledge proofs. (d) \textit{ProveLog} costs even an honest auditor: the only way for the client to ensure the auditor has fully followed the protocol is to run \textit{ProveLog} that requires the auditor to reveal its secret values. After that,  an honest auditor has to re-run the computationally expensive setup  again. Since the auditor is not trusted and no guarantee that it alerts the client as soon as the server's misbehaviour is detected, its involvement in the protocol seems unnecessary; and the whole scheme can be replaced with a much simpler one: the client, similar to a standard privately verifiable PoR, encodes its data and stores it in the server. Then, for each verification time, the server gets the random challenges from the blockchain and publishes  proofs in  bulletin board (to timestamp it). When the client comes online, it checks the proofs and accordingly takes the required action, e.g. pays the server, tries to recover the file.

Xu et al. in \cite{xu2016lightweight} propose a publicly verifiable PoR to improve the computation cost at setup. The scheme uses   BLS signatures-like tags, polynomial arithmetics, and polynomial commitments; unlike previous schemes,  each tag has a more complex structure.  In this protocol, an auditor is assumed to be fully trusted during the verifications. Later on, however, when  it is revoked by the client it may become malicious, i.e. may collude with the server and reveal its secret. This scheme allows a client to update its tags when a new auditor joins. To do that, the client needs to download all the blocks' tags, refresh them locally, and uploaded the fresh tags to the server. The verification for auditor and client involves public key operations and is more expensive than the one in \cite{armknecht2014outsourced}. The use of an auditor's revocation remains unclear in the paper, as  auditors are assumed to be honest in this protocol. A delegatable PDP is proposed in \cite{ShenT11} to ensure only authorised parties can verify the integrity of remote data. However, the delegated party in this scheme is fully trusted with the correctness of verification it performs. The scheme uses authenticator tags  similar to   BLS signatures based ones.

Very recently, proof of ``storage-time'' has been proposed in \cite{Storage-Time}. The paper proposes two protocols: basic PoSt and compact PoSt. At a high level, they offer the guarantee to a client that its data has been available on a remote storage server for a fixed time period: $T$.  The idea is that a client uploads to a server its data once, then  the server generates proofs of storage (e.g. PoR) periodically, collects them and sends the collection after the time $T$ to a verifier (i.e. client in basic PoSt or third-party in compact PoSt) who can check the proof. The first protocol, basic PoSt, uses Merkle tree-based PoR and VDF. In this protocol, The client precomputes a set of metadata (tags, challenges, and their related proofs). It  sends  the file, metadata, and a single challenge to the server. The server uses the  challenge to generate a PoR. It feeds the hash of the PoR to VDF to generate an output. It considers the hash of VDF's output as the next challenge from which  the next PoR is generated. This process goes on until all $z$ PoR's are generated. It sends all PoR proofs along with the proofs proving the correctness of VDF's outputs to a verifier. Given the two sets of proofs, a verifier can check their correctness and ultimately conclude that the file was retrievable within the time period. The scheme is publicly verifiable. However, the verification's computation cost is significant.  As, it requires  the validator to validate the correctness of VDF's outputs, that imposes a high cost. In total (for $z$ PoR proofs) it involves at least $3z$ modular exponentiations even if it uses  the fastest VDF, proposed in \cite{Wesolowski19}. Such costs are missed out and not taken into account in the paper. Moreover, the use of the Merkle tree introduces a high communication cost, as well. The authors suggest a smart contract can play the validator's role. However, we argue that this would impose a significant financial cost to the contract and users due to very high computation and communication costs stem from the verification and prove algorithms. The second protocol, compact PoSt, allows the server to combine PoR proofs that ultimately reduces the communication cost. The protocol's design is very similar to the previous one, but it replaces the Merkle tree approach with simply hashing the entire file and replaces the VDF with a trapdoor delay function (TDF) that requires a secret to generate/verify the delay function's output. Therefore, this protocol is only privately verifiable. The paper claims that the verification in this protocol can be performed by a trusted third-party, e.g. smart contract. Nevertheless, we argue that this is not the case. As,  the scheme requires a set of secrets (e.g. challenges) to perform the verification, while a smart contract does not maintain a private state. If the challenges are given to the contract, then the server can read the contract and compute all proofs in one go (which violates the security requirement set out in the paper). Moreover, the same security issue would arise in the case where the verification is delegated to a third-party auditor who may collude with the server (as the auditor can send all challenges to the server at once). Therefore, the only secure option, in the compact PoSt, is that  the verifier performs the validation itself (i.e. private verification/validation).  Note that   all the above outsourced PoR schemes \cite{armknecht2014outsourced,xu2016lightweight,Storage-Time}  assume the client behaves honestly towards the server. Otherwise, a malicious client can generate the tags in a way that  makes an honest server generate invalid proofs.

Hence, the existing outsourced PoR protocols either suffer from several security issues and guarantee no real-time detection or have to fully trust verifiers with the verification correctness, or are very inefficient.

 \subsubsection{Distributed PoR using a (Tailored) Blockchain}

Distributed  PoR allows  data to be distributed to numerous storage servers to achieve robustness, and address a single point of failure issue. Permacoin \cite{MillerPermacoin} is one of those  that distribute data among  customised blockchain nodes and  repurposes  mining resources of Bitcoin blockchain miners. In Permacoin, each miner needs to prove that it has a portion of the file and to do so it provides  proof of data retrievability verified by other miners. The miner, in this scheme needs to invest on both computation resources  and storage resources (to generate proof of retrievability). The protocol uses a Merkle tree built on top of file blocks to support publicly verifiable PoR. The mining procedure in this protocol is based on iterative hashing. In Permacoin, in each verification, the prover has to send both challenged file blocks and  the proof path in the tree, that imposes communication cost logarithmic to the size of the \emph{entire original file}.  In this scheme, an accepting proof only indicates a portion of the data holding by that miner (prover) is retrievable. Thus, for a data owner to have a guarantee that the entire data is retrievable, it  has to either wait for a long period of time (depending on the file size and the number of miners) or hope that there are enough active miners in each epoch.  Also, since the miners are both verifiers and provers (storage providers), it is assumed that the storage providers are economically rational (which is weaker than a malicious one). %Furthermore, the scheme suffers a vital security issue that allows a misbhaving miner to anticipate the challenge  file blocks for next rounds, if it is a miner for  consecutive blocks.  There are two protocols proposed in \cite{}, basic and advanced. The main difference between the two is that in the latter one the miner also signs a random index  and feeds the signature to the  procedure via which the next random index is created. For the sake of simplicity, we consider the basic protocol,  we will discus the same security issue is inherited by the advanced one as well. In particular, to compute a random index $r_{i}$, a miner computes $r_{i}=H(puz||pk||i||s)$ where $s$ is picked by the miner and $puz$ contains the header of previous block. Value $puz$ is the only source of randomness and would be unpredictable to the adversary if the previous block is proposed by an honest miner who includes a random $s$ in the block. However, if the adversary is chosen as a miner for $m$ consecutive blocks, then it can predict the random indices for every next $m-1$  blocks. Therefore, for a certain time period the POR (and Permacoin) security  is violated (e.g. can pre-compute the proof) and the availability of even the partial file is not guaranteed for a time period. Such issue does not hold in Bitcoin (with a high probability) as the randomness of each block is determined by a solution (nonce) of proof of work, not used in Permacoin.

Filecoin and KopperCoin in \cite{Filecoin,KoppBK16} respectively, offer  similar features, i.e. repurposing Bitcoin and supporting distributed PoR.  However, Filecoin, in addition to a Merkle tree, utilises  generic zero-knowledge proofs (i.e. zk-SNARKS) that result in a high  overall computation  cost and requires a trusted party to generate the system parameters. Filecoin uses proof of work as well as PoR. On the other hand,
 KopperCoin uses BLS signature-based publicly verifiable PoR that has a constant communication cost but has a high computation cost. Unlike Filecoin, KopperCoin does not use a PoW.

In the same line of research, \cite{KoppMHKB17} proposes a customised blockchain  that supports distributed PoR as well as  preserving the privacy of on-chain payments between storage users and providers. It however is computationally expensive as it uses publicly verifiable  tags based on  BLS signatures for PoR and ring signatures for the privacy-preserving payments.  Likewise, \cite{RujRBK18} proposes a high-level distributed PoR framework whose aim is efficient utilization of  storage resources offered by storage providers. It also uses BLS signatures and a Merkle tree along with a smart contract  for payments. Similarly, \cite{XueX0B18,XueXB19} propose  schemes that allow a user to store its encrypted data in the blockchain. The scheme uses a Merkle tree  for PoR   and a smart contract to transfer fees to the blockchain nodes storing  the data. In these two schemes, the data owner  is the party who sends random challenges  to  storage nodes, so it has to be  online when  verification is needed. Storj \cite{storj14} also falls in this category where there is a tailored blockchain comprising a set of storage nodes that store a part of data and provide  proofs when they are challenged. In Storj, there are trusted nodes, Satellite, who do the verifications on behalf of the clients.  The scheme uses a Merkle tree-based   PoR.

So,  existing distributed PoR protocols have either a large proof size or  high verification cost. Also,  they do not guarantee  that the \emph{entire} file is retrievable in  \emph{real-time}.

 \subsubsection{Verifying Remote (off-chain) data via a Blockchain}
 To relax the assumption that an auditor is fully trusted with the correctness of verification in the publicly verifiable PoR schemes while storing data off-chain, e.g. in a cloud, researchers proposed numerous protocols, e.g. \cite{RennerMK18,HaoXWJW18,ZhangDLZ18,Audita18,blockchain-data-audit-18,sia14}, that delegate the verification procedure  to blockchain nodes.  The high-level framework  proposed in \cite{RennerMK18} requires only a hash of the entire file is stored in a smart contract, where when later on the user access the file, it computes the hash of the file and compares it with the one stored in the contract. In this scheme, the entire file has to be accessed by the user for each verification which is what exactly PoR schemes avoid doing. The protocol  in \cite{HaoXWJW18} uses BLS signature-based tags and Merkle tree where the tags are broadcast to all blockchain nodes. However, surprisingly, the protocol assumes the cloud server is fully trusted and stores data safely, which raises the question that \textit{``why is a data verification needed in the first place?''}. In this protocol, the tags are generated by the cloud who sends them to the nodes. The tags are never checked against the outsourced data.  So, the only security guarantee \cite{HaoXWJW18} offers is the immutability of tags. The high-level scheme proposed in \cite{ZhangDLZ18} allows a client to pay the storage server in a fair manner. The scheme uses a blockchain for payment    and Merkle tree for PoR. In this protocol, the client has to be online and send random challenges to the server for every verification.

 Audita  \cite{Audita18} utilises an augmented blockchain and RSA signature-based  PDP  \cite{DBLP:conf/ccs/AtenieseBCHKPS07} to achieve its goal. In this scheme miners, for each epoch, pick a dealer who sends a challenge to the storage node(s) to get  proofs of data possession. Similar to Permacoin \cite{MillerPermacoin}, Audita substitutes proof of work with PDP, so if a proof is accepted a new block is added to the chain. But, in Audita every miner carries out  expensive public key based verifications.  The protocol proposed in \cite{blockchain-data-audit-18},   similar to \cite{armknecht2014outsourced}, uses a third-party auditor. It mainly utilises, a smart contract and  BLS signature-based tags. In this protocol, unlike \cite{armknecht2014outsourced},  when the auditor raises a dispute during the verification it calls a smart contract who performs the verification again to detect a misbehaving party, i.e. the server or auditor.  The protocol is computationally more expensive than \cite{armknecht2014outsourced} and inherits the same  issues, i.e. issues (a-c) stated above.  Sia \cite{sia14} is a mechanism in which a data owner  distributes  its data among off-chain storage servers who periodically provide a PoR  to a smart contract signed between the data owner and the servers. Each server gets paid if its proof is accepted by the contract. In this scheme, a Merkle tree-based PoR is used.

As evident,  the schemes designed for  blockchain-based verification of data stored in a storage server either require clients to access  whole outsourced data for  every verification, or impose a high communication/computation cost, or  clients have to be online for each verification.

 \subsubsection{Fair Exchange of Digital Services}

 Campanelli \textit{et al.}  \cite{CampanelliGGN17} propose a scheme that allows different parties to exchange digital services (and goods) over Bitcoin blockchain. This scheme, for instance in PoR context, allows the storage provider to get paid  if and only if the data owner receives an accepting proof. It has two variants, publicly and  privately verifiable both of which use a smart contract.   In addition, in the privately verifiable variant,  MAC-based tags and generic secure multi-party computation are used, e.g. Yao's garbled circuit \cite{Yao82b}, while in the publicly verifiable one  BLS signature tags and zk-SNARK are utilised.  Nevertheless, this scheme assumes that either the client is  available and online when PoR is provided (in privately verifiable variant) or the third party, acting on a client's behalf, performs PoR verification honestly (in publicly verifiable one).

%BonehBBF18,Wesolowski19


\section{Introduction}

%
% Secondly, many older type-inference algorithms typically use
% sets to collect constraints or substitutions for unification; these are hard to
% handle in the purely inductive style favored by theorem provers.

In summary the contributions of this paper are:

\begin{itemize}
\item {\bf A mechanical formalization of a polymorphic subtyping
    algorithm.} We show that the algorithm is \emph{sound},
  \emph{complete} and \emph{decidable} in the Abella theorem prover,
  and make the Abella formalization available online\footnote{\url{https://github.com/JimmyZJX/Abella-subtyping-algorithm}}.

\item {\bf Information propagation using worklist judgments:} we
  employ worklists judgments in our algorithmic specification of polymorphic subtyping
  to propagate information across judgments.

%\item {\bf Abella formalization and discussion.} We have a complete
%  Abella formalization of all the results, as well as discussions on
%  the advantages/disadvantages of using Abella for such formalization.
%  \tom{Where do we discuss the disadvantages?}\jimmy{Texts in this subsection~\ref{subsection:discussion} discuss the disadvantages: no user-defined tactics, lack of packages}
\end{itemize}