\documentclass{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
% \usepackage{amscd, amsfonts, amsmath, amssymb, amstext, amsthm, caption, epsfig, fancyhdr, float, graphicx, latexsym, mathtools, multicol, multirow, algorithm, chngcntr}
\usepackage[english, french]{babel}
\usepackage{booktabs}

\usepackage{amsmath,amssymb}
\usepackage{graphicx}
\usepackage{caption}
\usepackage{subfig}
\usepackage{xspace}
\usepackage{fourier}

\usepackage{tikz}
\usetikzlibrary{shapes,arrows}
\usepackage{tkz-graph}
\usetikzlibrary{automata,arrows,positioning,calc}
\usetikzlibrary{positioning}
\usetikzlibrary{fit}
\usetikzlibrary{backgrounds}
\usetikzlibrary{calc}
\usetikzlibrary{shapes}
\usetikzlibrary{mindmap}
\usetikzlibrary{decorations.text}

% \theoremstyle{definition} % insert bellow all blocks you want in normal text
% \newtheorem{definition}{Definition}

% tikzmark command, for shading over items
\newcommand{\tikzmark}[1]{\tikz[overlay,remember picture] \node (#1) {};}
% Define block styles
\tikzstyle{decision} = [diamond, draw, fill=blue!20,
    text width=4.5em, text badly centered, node distance=3cm, inner sep=0pt]
\tikzstyle{block} = [rectangle, draw, fill=blue!20,
    text width=5em, text centered, rounded corners]
\tikzstyle{line} = [draw]
\tikzstyle{cloud} = [draw, ellipse,fill=red!20, node distance=3cm,
    minimum height=2em]

\usepackage[most]{tcolorbox}

\setbeamertemplate{blocks}[rounded][shadow=true] % use rounded blocks with standard beamer shadow
\setbeamertemplate{theorems}[numbered]

% \newcommand*{\warning}{\fontencoding{U}\fontfamily{futs}\selectfont\char 66\relax}

% Distributions.
\newcommand*{\UnifDist}{\mathsf{Unif}}
\newcommand*{\ExpDist}{\mathsf{Exp}}
\newcommand*{\DepExpDist}{\mathsf{DepExp}}
\newcommand*{\GammaDist}{\mathsf{Gamma}}
\newcommand*{\LognormalDist}{\mathsf{LogNorm}}
\newcommand*{\WeibullDist}{\mathsf{Weib}}
\newcommand*{\ParetoDist}{\mathsf{Par}}
\newcommand*{\NormalDist}{\mathsf{Norm}}

\newcommand*{\GeometricDist}{\mathsf{Geom}}
\newcommand*{\NegBinomialDist}{\mathsf{NegBin}}
\newcommand*{\PoissonDist}{\mathsf{Poisson}}
\newcommand*{\BivariatePoissonDist}{\mathsf{BPoisson}}
\newcommand*{\CyclicalPoissonDist}{\mathsf{CPoisson}}

\newcommand*{\iid}{\textbf{iid}\@\xspace}
\newcommand*{\pdf}{\textbf{pdf}\@\xspace}
\newcommand*{\cdf}{\textbf{cdf}\@\xspace}
\newcommand*{\pmf}{\textbf{pmf}\@\xspace}
\newcommand*{\abc}{{\textbf{abc}}\@\xspace}
\newcommand*{\smc}{\textbf{smc}\@\xspace}
\newcommand*{\mcmc}{\textbf{mcmc}\@\xspace}
\newcommand*{\ess}{\textbf{ess}\@\xspace}
\newcommand*{\mle}{\textbf{mle}\@\xspace}
\newcommand*{\bic}{\textbf{bic}\@\xspace}
\newcommand*{\kde}{\textbf{kde}\@\xspace}
\newcommand*{\glm}{\textbf{glm}\@\xspace}
\newcommand*{\xol}{\textbf{xol}\@\xspace}
\newcommand*{\cpu}{\textbf{cpu}\@\xspace}
\newcommand*{\gpu}{\textbf{gpu}\@\xspace}
\newcommand*{\arm}{\textbf{arm}\@\xspace}

\def \si {\sigma}
\def \la {\lambda}
\def \al {\alpha}
% \def\e*{\end{eqnarray*}}
\def \di{\displaystyle}

\def \E{\mathbb E}
\def \N{\mathbb N}
\def \Z{\mathbb Z}
\def \NZ{\mathbb{N}_0}
\def \I{\mathbb I}
\def \w{\widehat}
\def \P {\mathbb P}
\def \V{\mathbb V}

\newcommand{\CL}{\mathbb{C}}
\newcommand{\RL}{\mathbb{R}}
\newcommand{\nat}{{\mathbb N}}
\newcommand{\Laplace}{\mathscr{L}}
\newcommand{\e}{\mathrm{e}}
\newcommand{\ve}{\bm{\mathrm{e}}} % vector e

\renewcommand{\L}{\mathcal{L}} % e.g. L^2 loss.

\newcommand{\ih}{\mathrm{i}}
\newcommand{\oh}{{\mathrm{o}}}
\newcommand{\Oh}{{\mathcal{O}}}
\newcommand{\Exp}{\mathbb{E}}

\newcommand{\Norm}{\mathcal{N}}
\newcommand{\LN}{\mathcal{LN}}
\newcommand{\SLN}{\mathcal{SLN}}

\renewcommand{\Pr}{\mathbb{P}}
\newcommand{\Ind}{\mathbb I}
\newcommand\bfsigma{\bm{\sigma}}
\newcommand\bfSigma{\bm{\Sigma}}
\newcommand\bfLambda{\bm{\Lambda}}
\newcommand{\stimes}{{\times}}
\def \limsup{\underset{n\rightarrow+\infty}{\overline{\lim}}}
\def \liminf{\underset{n\rightarrow+\infty}{\underline{\lim}}}

% vertical separator macro
\newcommand{\vsep}{
  \column{0.0\textwidth}
    \begin{tikzpicture}
      \draw[very thick,black!10] (0,0) -- (0,7.3);
    \end{tikzpicture}
}
\newcommand\blfootnote[1]{%
  \begingroup
  \renewcommand\thefootnote{}\footnote{#1}%
  \addtocounter{footnote}{-1}%
  \endgroup
}

% More space between lines in align
% \setlength{\mathindent}{0pt}

% Beamer theme
\usetheme{ZMBZFMK}
\usefonttheme[onlysmall]{structurebold}
\mode<presentation>
\setbeamercovered{transparent=10}

% align spacing
\setlength{\jot}{0pt}

\setbeamertemplate{navigation symbols}{}%remove navigation symbols

\title[BLOCKASTICS III]{Stochastic Models for blockchain analysis}
\subtitle{Blockchain risk analysis}
\author{Pierre-O. Goffard}
\institute[ISFA]{Institut de Science Financières et d'Assurances\\
 \texttt{pierre-olivier.goffard@univ-lyon1.fr}}
\date{\today}
\titlegraphic{\includegraphics[width=2.5cm]{../../../Figures/bfs_logo.png}}

\begin{document}
\begin{frame}
  \titlepage
\end{frame}
\begin{frame}{Blockchain risk analysis}
\tableofcontents
% \begin{enumerate}
%   \item Security of PoW blockchain
%   \item Decentralization in PoS blockchain
%   \item Blockhain efficiency
% \end{enumerate}
\end{frame}
\section{Insurance risk theory}
\begin{frame}{Cramer-Lunberg model}
\begin{columns}
\begin{column}{0.5\textwidth}
\scriptsize
The financial reserves of an insurance company over time have the following dynamic
\begin{equation*}
R_t = z +ct - \sum_{i = 1}^{N_t}U_i\text{, }t\geq0,
\end{equation*}
where
\begin{itemize}
  \item $z>0$ denotes the initial reserves
  \item $c$ is the premium rate
  \item $(N_t)_{t\geq0}$ is a counting process that models the claim arrival
  \begin{itemize}
    \scriptsize
    \item[$\hookrightarrow$]  Poisson process with intensity $\lambda$
  \end{itemize}
  \item The $U_i$'s are the randomly sized compensations
  \begin{itemize}
    \scriptsize
    \item[$\hookrightarrow$] non-negative, \textbf{i.i.d.}
  \end{itemize}
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\begin{tikzpicture}
  %Origin and axis
  \coordinate (O) at (0,0);
  \draw[->] (-0.5,0) -- (5.5,0) coordinate[label = {below:\scriptsize$t$}] (xmax);
  \draw[->] (0,-0.5) -- (0,4) coordinate[label = {right:\scriptsize$R_t$}] (ymax);
   %Initial reserves
  \draw (0,2) node[black,left] {\scriptsize$z$} node{};
 % % %Length of the honest chain
  \draw[thick, tublue,-] (0,2) -- (2,3) node[pos=0.5, above] {};
  \draw[thick, dashed, tublue] (2,3) -- (2,1) node[pos=0.5, left] {\scriptsize\color{black}$U_1$};
  \draw[thick, tublue] (2,1) -- (3,1.5) node[pos=0.5, above] {};
  \draw[thick, dashed, tublue] (3,1.5) -- (3, 0.5) node[pos=0.5, left] {\scriptsize\color{black}$U_2$};
  \draw[thick, tublue] (3,0.5) -- (5, 1.5) node[pos=0.5, above] {};
   \draw[thick, dashed, tublue] (5,1.5) -- (5, -0.5) node[pos=0.5,above left] {\scriptsize\color{black}$U_3$};

  %Block finding Times
  \draw (2,0) node[black,below] {\scriptsize$T_1$} node{ \color{black}$\bullet$};
  \draw (3,0) node[black,below] {\scriptsize$T_2$} node{ \color{black}$\bullet$};
  \draw (5,0) node[black,below left] {\scriptsize$\tau_z$} node{ \color{black}$\bullet$};
\end{tikzpicture}
\end{column}
\end{columns}

\end{frame}
\begin{frame}{Ruin probabilities}
\scriptsize
Define the ruin time as
$$
\tau_z = \inf\{t\geq0\text{ ; }R_t <0\}
$$
and the ruin probabilities as
$$
\psi(z,t) = \mathbb{P}(\tau_z < t)\text{ and }\psi(z) = \mathbb{P}(\tau_z < \infty)
$$
We look for $z$ such that
$$
\mathbb{P}(\text{Ruin}) = \alpha\text{ (0.05)},
$$
given that
$$
c=(1+\eta)\lambda\mathbb{E}(U),
$$
with
$$\eta>0\text{ (net profit condition)}$$
otherwise
$$\psi(z)=1.$$

\tiny
\begin{thebibliography}{1}

\bibitem{Asmussen_2010}
S.~Asmussen and H.~Albrecher, {\em Ruin Probabilities}.
\newblock {WORLD} {SCIENTIFIC}, sep 2010.

\end{thebibliography}

\end{frame}

\begin{frame}{Ruin probability computation}
\scriptsize
Let
$$
S_t = z - R_t,\text{ }t\geq0
$$
\begin{tcolorbox}[enhanced,drop shadow, title=Theorem (Wald exponential martingale)]
If $(S_t)_{t\geq0}$ is a L\'evy process or a random walk then
$$
\{\exp\left[\theta S_t-t\kappa(\theta)\right]\text{ , }t\geq0\},\text{ is a martingale,}
$$
where $\kappa(\theta)=\log\mathbb{E}\left(e^{\theta S_1}\right)$.
\end{tcolorbox}
\begin{tcolorbox}[enhanced,drop shadow, title=Theorem (Representation of the ruin probability)]

If $S_t\overset{\textbf{a.s.}}{\rightarrow} -\infty$, and there exists $\gamma>0$ such that $\{e^{\gamma S_t}\text{ , }t\geq0\}$ is a martingale then
$$
\mathbb{P}(\tau_z<\infty)=\frac{e^{-\gamma z}}{\mathbb{E}\left[e^{\gamma \xi(z)}|\tau_z<\infty\right]},
$$
where $\xi(z)=S_{\tau_z}-z\text{ denotes the deficit at ruin.}$
\end{tcolorbox}
\end{frame}
\begin{frame}{Sketch of Proof}
\scriptsize
\begin{itemize}
\item Because of the net profit condition $S_t = \sum_{i=1}^{N_t}U_i-ct\rightarrow -\infty$ as $t\rightarrow\infty$
\item $(S_t)_{t\geq0}$ is a Lévy process, let $\gamma$ be the (unique, positive) solution to
$$
\kappa(\theta) = 0\text{ (Cramer-Lundberg equation)}.
$$
\item  $(e^{\gamma S_t})_{t\geq0}$ is a Martingale then apply the Optional stopping theorem at $\tau_z$.

\end{itemize}
\end{frame}
\section{Link to double spending}
\begin{frame}{Double spending in Satoshi's framework}
\scriptsize
\begin{itemize}
\item The risk reserve process is $R_t=z+Y_1+\ldots+Y_t.$
\item The claim surplus process is $S_t=-(Y_1+\ldots+Y_t).$
\item $\kappa(\theta)=0$ is equivalent to
$$pe^{-\theta}+qe^{\theta}=1.$$
\begin{itemize}
\item[$\hookrightarrow$]\scriptsize $\gamma=\log(p/q).$
\end{itemize}
\item If $p>q$ then $S(t)\rightarrow - \infty$.
\item  $\xi(z)=S_{\tau_z}-z=0$ \textbf{a.s}.
\end{itemize}
Thus,
$$\mathbb{P}(\tau_z<\infty)=\left(\frac{q}{p}\right)^{z}.$$
\end{frame}

\begin{frame}{Double spending with Poisson processes}
\begin{columns}
\begin{column}{0.5\textwidth}
\scriptsize
\begin{itemize}
\item Suppose that
$$
N_t\sim\text{Pois}(\lambda t)\text{ and }M_t\sim\text{Pois}(\mu t)
$$
such that $\lambda>\mu$.
\item The risk reserve process is $R_t=z+N_t-M_t.$
\item The claim surplus process is $S_t=M_t-N_t.$
\end{itemize}
\begin{tcolorbox}[enhanced,drop shadow, title=Fact]
The difference of two Poisson processes is not a Poisson process, However it is L\'evy!
\end{tcolorbox}
\end{column}
\begin{column}{0.5\textwidth}
\begin{tikzpicture}
  %Origin and axis
  \coordinate (O) at (0,0);
  \draw[->] (-0.5,0) -- (5.5,0) coordinate[label = {above:\scriptsize$t$}] (xmax);
  \draw[->] (0,-0.5) -- (0,5) coordinate[label = {right:\scriptsize$n$}] (ymax);
 %Length of the honest chain
  \draw[thick,tublue,-] (0,3) -- (2,3) node[pos=0.5, above] {} ;
  \draw[thick,tublue] (2,3) -- (2,4) node[pos=0.5, above] {};
  \draw[thick,tublue] (2,4) -- (5.5,4) node[pos=0.5, right] {};
  % %Length of the Malicious chain
  \draw[very thick,dashed,red,-] (0,0) -- (0.75,0) node[pos=0.5, above] {} ;
  \draw[very thick,dashed,red] (0.75,0) -- (0.75,1) node[pos=0.5, right] {};
  \draw[very thick,dashed,red] (0.75,1) -- (1.25,1) node[pos=0.5, above] {};
  \draw[very thick,dashed,red] (1.25,1) -- (1.25,2) node[pos=0.5, right] {};
  \draw[very thick,dashed,red] (1.25,2) -- (2.5,2) node[pos=0.5, above] {};
  \draw[very thick,dashed,red] (2.5,2) -- (2.5,3) node[pos=0.5, right] {};
  \draw[very thick,dashed,red] (2.5,3) -- (5,3) node[pos=0.5, right] {};
  \draw[very thick,dashed,red] (5,3) -- (5,4) node[pos=0.5, above] {};
  \draw[very thick,dashed,red] (5,4) -- (5.5,4) node[pos=0.5, above] {};
  %Jump Times of the malicious chain
  \draw (0.75,0) node[red,below] {\scriptsize$S_1$} node{ \color{red}$\bullet$};
  \draw (1.25,0) node[red,below] {\scriptsize$S_2$} node{ \color{red}$\bullet$};
  \draw (2.5,0) node[red,below] {\scriptsize$S_3$} node{ \color{red}$\bullet$};
  \draw (5,0) node[black,below] {\scriptsize$S_4=\tau_z$} node{ \color{black}$\bullet$};
  % %Jump Times of the honest chain
  \draw (2,0) node[tublue,below] {\scriptsize$T_1$} node{ \color{tublue}$\bullet$};
  % %Aggregated Capital gains
  \draw (0,1) node[black,left] {\scriptsize$1$} node{ \color{black}$-$};
  \draw (0,2) node[black,left] {\scriptsize$2$} node{ \color{black}$-$};
  \draw (0,3) node[black,left] {\scriptsize$z$} node{};
  \draw (0,4) node[black,left] {\scriptsize$4$} node{ \color{black}$-$};
  % %Ruin time = First-meeting time
  % \draw (7,0) node[black,below] {$\tau_z$} node{ \color{black}$\times$};
  % \draw[dotted,black] (7,3) -- (7,0);
\end{tikzpicture}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Double spending with Poisson processes}
\scriptsize
\begin{itemize}
\item $\kappa(\theta)=0$ is equivalent to
$$
\mu e^{\theta}+\lambda e^{-\theta}-(\lambda+\mu)=0.
$$

\begin{itemize}
\item[$\hookrightarrow$] $\gamma=\log(\lambda/\mu).$
\end{itemize}
\item If $\lambda>\mu$ then $S_t\rightarrow - \infty$.
\item $\xi(z)=S_{\tau_z}-z=0$ \textbf{a.s}.
\end{itemize}
Thus
$$\mathbb{P}(\tau_z<\infty)=\left(\frac{\mu}{\lambda}\right)^{z}.$$

\end{frame}

\begin{frame}{Double spending cost}
\scriptsize
Mining cryptocurrency in PoW equipped blockchain is energy consuming
\begin{itemize}
\item[$\hookrightarrow$] Operational cost for miners
\end{itemize}
Per time unit a miner pays
$$
c = \pi_W\cdot W\cdot q,
$$
where
\begin{itemize}
  \item $\pi_W$ is the electricty price per kWh
  \item $W$ is the consumption of the network \url{https://cbeci.org/}
  \item  $q$ is the attacker's hashpower
\end{itemize}
\begin{tcolorbox}[enhanced,drop shadow, title=Fact]
The cost of double spending is $c\cdot \tau_z$.
\end{tcolorbox}
\begin{tcolorbox}[enhanced,drop shadow, title=Theorem (\textbf{P.d.f.} of the double spending time)]
If $\{N_t\text{ , }t\geq0\}$ is a Poisson process then the \textbf{p.d.f.} of $\tau_z$ is given by
\begin{equation*}
f_{\tau_z}(t)=\mathbb{E}\left[\frac{z}{z+N_t}f_{S_{N_t+z}}(t)\right],\text{ for }t\geq0.
\end{equation*}
\end{tcolorbox}
\end{frame}
\begin{frame}{Sketch of the proof}
\scriptsize
Let's condition upon the values of $N_t$,
\begin{itemize}
  \item if $N_t=0$ then
  $$\tau_z = S_z\text{ and }f_{\tau_z|N_t=0}(t) = f_{S_z}(t)$$
  \item If $N_t = n$ for $n\geq 1$ then
  $$
  \{\tau_z = t\} = \bigcup_{k = 1}^n\{T_k\leq S_{z+k-1}\}\cup\{S_{n+z} = t\}
  $$
We have
\begin{eqnarray*}
f_{\tau_z|N_t = n}(t) &=& \mathbb{P}(U_{1:n}\leq S_z/t,\ldots,U_{n:n}\leq S_{z+n-1}/t\Big\rvert S_{n+z}=t)f_{S_{n+z}}(t)\\
&=&\frac{z}{z+n}f_{S_{n+z}}(t).
\end{eqnarray*}
Thanks to the properties of the Abel-Gontcharov polynomials.
\end{itemize}
\tiny
\begin{thebibliography}{1}

\bibitem{Goffard2019}
P.-O. Goffard, ``Fraud risk assessment within blockchain transactions,'' {\em
  Advances in Applied Probability}, vol.~51, pp.~443--467, jun 2019.
\newblock \url{https://hal.archives-ouvertes.fr/hal-01716687v2}.
\bibitem{Grunspan2021}
C.~Grunspan and R.~P{\'{e}}rez-Marco, ``{ON} {PROFITABILITY} {OF} {NAKAMOTO}
  {DOUBLE} {SPEND},'' {\em Probability in the Engineering and Informational
  Sciences}, pp.~1--15, feb 2021.

\bibitem{Brown2020}
M.~Brown, E.~Peköz, and S.~Ross, ``{BLOCKCHAIN} {DOUBLE}-{SPEND} {ATTACK}
  {DURATION},'' {\em Probability in the Engineering and Informational
  Sciences}, pp.~1--9, may 2020.

\bibitem{Jang2020}
J.~Jang and H.-N. Lee, ``Profitable double-spending attacks,'' {\em Applied
  Sciences}, vol.~10, p.~8477, nov 2020.

\end{thebibliography}
\end{frame}

\section{Link to blockchain mining}
\begin{frame}{Dual risk model}
\begin{columns}
\begin{column}{0.5\textwidth}
\scriptsize
A blockchain miner with hashpower share $p\in(0,1)$ that
\begin{itemize}
  \item owns $u\geq0$ at the beginning
  \item spend $c = \pi_W\cdot W\cdot p$ per time unit
  \item finds block at a rate $p \lambda$, where $\lambda$ is the arrival rate of blocks
\end{itemize}
The miner's surplus is given by
$$
R_t = u - c\cdot t + N_t\cdot b,\text{ (Dual risk model)}
$$
where
\begin{itemize}
  \item $(N_t)_{t\geq0}$ is a Poisson process with intensity $p\cdot\lambda$
  \item $b$ is the block finding reward (6.25 BTC) \url{bitcoinhalf.com}
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\begin{tikzpicture}
  %Origin and axis
  \coordinate (O) at (0,0);
  \draw[->] (-0.5,0) -- (5.5,0) coordinate[label = {below:\scriptsize$t$}] (xmax);
  \draw[->] (0,-0.5) -- (0,4) coordinate[label = {right:\scriptsize$R_t$}] (ymax);
   %Initial reserves
  \draw (0,3) node[black,left] {\scriptsize$u$} node{};
 % % %Length of the honest chain
  \draw[thick, tublue,-] (0,3) -- (2,1) node[pos=0.5, above] {};
  \draw[thick, dashed, tublue] (2,1) -- (2,2) node[pos=0.5, above left] {\scriptsize\color{black}$b$};
  \draw[thick, tublue] (2,2) -- (3.5,0.5) node[pos=0.5, above] {};
  \draw[thick, dashed, tublue] (3.5,0.5) -- (3.5, 1.5) node[pos=0.5, above left] {\scriptsize\color{black}$b$};
  \draw[thick, tublue] (3.5,1.5) -- (5, 0) node[pos=0.5, above] {};

  %Block finding Times
  \draw (2,0) node[black,below] {\scriptsize$T_1$} node{ \color{black}$\bullet$};
  \draw (3.5,0) node[black,below] {\scriptsize$T_2$} node{ \color{black}$\bullet$};
  \draw (5,0) node[black,below] {\scriptsize$\tau_u$} node{ \color{black}$\bullet$};
\end{tikzpicture}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Expected profit given not ruin}
\scriptsize

\begin{tcolorbox}[enhanced,drop shadow, title=Fact]
The steady operational cost compensated by infrequent capital gains makes mining a risky business.
\end{tcolorbox}
Define the ruin time
$$
\tau_u  = \inf\{t\geq0\text{ ; }R_t \leq0\}
$$
\begin{itemize}
  \item Risk measure
  $$
  \psi(u,t) = \mathbb{P}(\tau_u \leq t)
  $$
  \item Profitability measure
  $$
  V(u,t) = \mathbb{E}(R_t\mathbb{I}_{\tau_u > t})
  $$
\end{itemize}
\end{frame}
\begin{frame}{Miner's dilemna}
\scriptsize
Use $\psi$ and $V$ to compare solo mining to
\begin{itemize}
  \item Joining a mining pool
\tiny
  \begin{thebibliography}{1}

\bibitem{rosenfeld2011analysis}
M.~Rosenfeld, ``Analysis of bitcoin pooled mining reward systems,'' 2011.

\bibitem{albrecher2021blockchain}
H.~Albrecher, D.~Finger, and P.-O. Goffard, ``Blockchain mining in pools:
  Analyzing the trade-off between profitability and ruin,'' 2021.

\end{thebibliography}
  \item \scriptsize Deviating from the protocol (selfish mining)

  \tiny
  \begin{thebibliography}{1}
  \bibitem{Eyal2014}
I.~Eyal and E.~G. Sirer, ``Majority is not enough: Bitcoin mining is
  vulnerable,'' in {\em Financial Cryptography and Data Security},
  pp.~436--454, Springer Berlin Heidelberg, 2014.

\bibitem{albrecher:hal-02649025}
H.~Albrecher and P.-O. Goffard, ``{On the profitability of selfish blockchain
  mining under consideration of ruin},'' {\em To appear in Operations
  Research}, May 2021.
\newblock \url{https://arxiv.org/abs/2010.12577}.
\end{thebibliography}
\end{itemize}
Tractable formulas follow from
$$
\widehat{\psi}(u,t)= \mathbb{E}[\psi(u,T)]\text{ and }\widehat{V}(u,t)= \mathbb{E}[V(u,T)],
$$
where $T\sim\text{Exp}(t)$.
\end{frame}

\begin{frame}{When mining solo}
\scriptsize
\begin{tcolorbox}[enhanced,drop shadow, title=Theorem (profit and ruin when mining solo)]
For any $u\geq0$, we have
\begin{equation*}
\widehat{\psi}(u,t) = e^{\rho^\ast u},
\end{equation*}
and
\begin{equation*}
\widehat{V}(u,t) = u+(p\lambda b-c)t\left(1-e^{\rho^\ast u }\right),
\end{equation*}
where $\rho^\ast$ is the negative solution of the equation
\begin{equation}\label{eq:equation_rho}
-c\rho + p\lambda(e^{b\rho}-1) = 1/t.
\end{equation}
\end{tcolorbox}
\begin{tcolorbox}[enhanced,drop shadow, title=Lambert function]
The solution $\rho^\ast$ of \eqref{eq:equation_rho} is given by
\begin{equation*}
  \rho^{\ast}=-\frac{p \lambda t+1}{ct}
  -\frac{1}{b} \,{\rm W} \left[-\frac{p\lambda
    \,b}{c}\,{e^{-b\,\left(\frac{p \lambda t+1}{ct}\right)}}
  \right],
  \end{equation*}
  where $W(.)$ denotes the Lambert function.
\end{tcolorbox}
\end{frame}
\begin{frame}[allowframebreaks]{Sketch of the proof}
\scriptsize
Recall that the time horizon is random $T\sim\text{Exp}(t)$, we condition upon what happen during the time interval $(0,h)$, with $h<u/c$ so that ruin does not occur before $h$. Three possibilities
\begin{itemize}
  \item[(i)] $T>h$ and there is no block discovery during $(0,h)$
  \item[(ii)] $T<h$ and there is no block discovery during $(0,T)$
  \item[(iii)] There is a block discovery before time $T$ and in the interval $(0,h)$
\end{itemize}
For the expected profit $\widehat{V}(u,t)$, we get
\begin{eqnarray*}
  \widehat{V}(u,t)& =&e^{-h(1/t + p\lambda)}\,\widehat{V}(u-ch,t)+\int\limits_0^h\frac1t\, e^{-s(1/t + p\lambda)}\,(u-cs)ds\\
  &+&\int\limits_0^h p\lambda\, e^{-s(1/t + p\lambda)}\,\widehat{V}(u-cs+b,t)ds.
  \end{eqnarray*}
  \end{frame}
\begin{frame}{Sketch of the proof}
\scriptsize
Now we take the derivative with respect to $h$ and set $h=0$ to obtain
\begin{equation}\label{eq:ODE}
c\widehat{V}'(u,t) + \left(\frac{1}{t} +  p\lambda\right)\widehat{V}(u,t) - p\lambda \widehat{V}(u+b,t) - \frac{u}{t} =0,
\end{equation}
Equation \eqref{eq:ODE} is an advanced functional differential equation\blfootnote{\tiny
 H.~L. Smith, {\em An introduction to delay differential equations with
  applications to the life sciences}.
\newblock Springer, New York, 2011.
}
with boundary condition
$$
\widehat{V}(0,t) = 0 \text{ and such that } 0\leq \widehat{V}(u,t)\leq u-ct+p\lambda b t \text{ for }u>0.
$$
Consider solutions of the form
\begin{equation}\label{eq:potential_solution}
\widehat{V}(u,t) = Ae^{\rho u }+Bu + C,\text{ }u \ge 0,
\end{equation}
where $A, B,C$ and $\rho$ are constants to be determined. Substituting \eqref{eq:potential_solution} in \eqref{eq:ODE} together with the boundary condition yields the system of equations
\begin{equation*}
\begin{cases}
0&=ct\rho + \left(1+p\lambda t\right)-p\lambda te^{\rho b}, \\
0&= B\left(1+tp\lambda\right)-p\lambda tB - 1,\\
0&=Bct+C(1+tp\lambda) - p\lambda t Bb-p\lambda tC, \\
0&=A+C.
\end{cases}
\end{equation*}
\end{frame}
\begin{frame}{Sketch of the proof}
\scriptsize
We then have $A = -t(p\lambda b - c)$, $B = 1$, $C = t(p\lambda b - c)$ and $\rho$ is solution of
$$
c\rho + \left(1+p\lambda t\right)-p\lambda te^{\rho b} = 0,
$$
which admits one negative and one positive solution. As $A<0$, we have to choose the negative solution $\rho^\ast<0$ in order to ensure $\widehat{V}(u,t)>0$. Substituting $A,B,C$ and $\rho^{\ast}$ in \eqref{eq:potential_solution}  yields the result.\\

Similarly, the ruin probability is solution to
\begin{equation*}\label{psii}
c\widehat{\psi}'(u,t)+(p \lambda+1/t)\,\widehat{\psi}(u,t)-p \lambda\,\widehat{\psi}(u+b,t)=0
\end{equation*}
with initial condition $\widehat{\psi}(0,t)=1$ and boundary condition $\lim_{u\to\infty}\widehat{\psi}(u,t)=0$.
\end{frame}
\begin{frame}{How does a mining pool works?}
\scriptsize
A set of miners $I\subset\{1,\ldots, n\}$ join forces and gather a share
$$
p_I = \sum_{i\in I }p_i,
$$
of the total mining power.
\begin{itemize}
  \item a pool manager coordinates
  \item miners prove their contribution by submiting \textit{shares}
\end{itemize}
\begin{tcolorbox}[enhanced,drop shadow, title=Definition (share)]
A \textit{share} is a partial solution to the cryptopuzzle
\end{tcolorbox}
The pool manager sets
\begin{itemize}
  \item the redistribution system
  \item the relative difficulty $q\in(0,1)$ of finding a \textit{share} compared to finding a block
  \item the pool participation fee $f$
  \end{itemize}
\end{frame}
\begin{frame}{Redistribution systems}
\scriptsize
Miners should be retributed in proportion to their contribution to the mining effort.
\begin{tcolorbox}[enhanced,drop shadow, title=Proportional reward system]
A \textit{round} is the time elapsed between two block discoveries
\begin{itemize}
  \item $s_i$ the number of shares submitted by miner $i\in I$ during the \textit{round}
  \item Each miner receives at the end of the \textit{round}
  $$
  (1-f)\cdot b\cdot\frac{s_i}{\sum_{i\in I}s_i},
  $$
  where $f$ represents the pool manager's cut.
  \item The system is fair as $\frac{s_i}{\sum_{i\in I}s_i}$ should converges toward $\frac{p_i}{\sum_{i\in I}p_i}$
\end{itemize}

\end{tcolorbox}
\end{frame}
\begin{frame}{What's wrong with going proportional?}
\scriptsize
\begin{tcolorbox}[enhanced,drop shadow, title=Fact]
The proportional reward system is fair but it is not incentive compatible
\end{tcolorbox}
\tiny
\begin{thebibliography}{1}

\bibitem{Schrijvers2017}
O.~Schrijvers, J.~Bonneau, D.~Boneh, and T.~Roughgarden, ``Incentive
  compatibility of bitcoin mining pool reward functions,'' in {\em Financial
  Cryptography and Data Security}, pp.~477--498, Springer Berlin Heidelberg,
  2017.

\end{thebibliography}
\scriptsize
Why?
\begin{itemize}
  \item The durations of a round is random
  \begin{itemize}
    \scriptsize
    \item[$\hookrightarrow$] A \textit{share} is worth less in longer round $\Rightarrow$ \textit{pool hoping} \tiny
    \begin{thebibliography}{1}

\bibitem{rosenfeld2011analysis}
M.~Rosenfeld, ``Analysis of bitcoin pooled mining reward systems,'' 2011.

\end{thebibliography}
\scriptsize
    \item[$\hookrightarrow$] Apply a discounting factor on the value of a \textit{share} \tiny
    \begin{thebibliography}{1}
\bibitem{slush}
slush pool, ``Reward system specifications,'' 2021.
\end{thebibliography}
  \end{itemize}
  \item A miner may postpone the communication of a solution
  \begin{itemize}
    \scriptsize
    \item[$\hookrightarrow$] She may awaits for her number of \textit{share} to match her actual hashpower
  \end{itemize}
  \item Absolutely no risk tranfer from miners to manager
    \begin{itemize}
    \scriptsize
    \item[$\hookrightarrow$] $f$ should be low
  \end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{Pay-per-Share (PPS) reward system}
\scriptsize
The pool manager gives out
$$
w = (1-f)\cdot q \cdot b
$$
for each submitted share and keep the block reward.
\vspace{1cm}
\begin{columns}
\begin{column}{0.5\textwidth}
Miner's viewpoint
$$
R_t^i = u_i-ct + M_t^i w,\text{ }t\geq0.
$$
where
\begin{itemize}
   \item $(M_t^i)_{t\geq0}$ is a Poisson process with intensity $p_i \mu= p_i\lambda / q$
   \item $\mu$ corresponds to the rate at which the network find \textit{shares}
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
Manager's viewpoint
$$
R_t^I = u_I - M_t^I w+N_t^I b,\text{ }t\geq0.
$$
where
\begin{itemize}
   \item $(M_t^I)_{t\geq0}$ is a Poisson process with intensity $p_I\mu =p_I\lambda / q$
   \item $(N_t^I)_{t\geq0}$ is a Poisson process with intensity $p_I\lambda$
\end{itemize}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Pool manager at risk?}
\scriptsize
For mathematical convenience we replace the deterministic reward by stochastic ones, the wealth of the pool manager becomes
$$
R_t= u - \sum_{i=1}^{M_t} W_i +\sum_{j=1}^{N_t} B_j,\text{ }t\geq0.
$$
where
\begin{itemize}
  \item $(M_t)_{t\geq0}$ and $(N_t)_{t\geq0}$ are Poisson processes with intensity $\mu^\ast=\mu- \lambda$ and $\lambda$
  \item $(W_i)_{i\geq0}$ and $(B_j)_{j\geq0}$ are two independent sequence of \iid exponentially distributed random variables with mean $w$ and $b^\ast = b-w$
\end{itemize}
\begin{tcolorbox}[enhanced,drop shadow, title=Poisson process superposition]
A block discovery triggers automatically a payment to the miner, specifying
\begin{itemize}
\item the intensity of $M_t$ as $\mu^\ast=\mu- \lambda$
\item the size of the upward jumps as $b^\ast = b-w$
\end{itemize}
allows us to isolate the downward jumps and make the Poisson processes independent.
\end{tcolorbox}
\end{frame}
\begin{frame}{Pool manager at risk?}
\scriptsize
\begin{tcolorbox}[enhanced,drop shadow, title=Theorem (Profit and ruin of the pool manager)]
The ruin probability is given by
\begin{equation*}\label{psiexpe}
    \widehat{\psi}(u,t) = (1-Rw)  e^{-R u},\;u\ge 0,
\end{equation*}
and the expected profit is given by
\begin{equation*}\label{Vcombexpe}
    \w{V}(u,t) = (1 - Rw)[w-t(\lambda b^\ast-\mu^\ast w)] e^{-R u}+u+t(\lambda b^\ast-\mu^\ast w),
\end{equation*}
where $R$ is the (unique) solution with positive real part of
\begin{equation*} \label{VLunde}
    -(t^{-1}+\lambda+\mu^\ast)+\lambda(1+b^\ast r)^{-1}+\mu^\ast(1-wr)^{-1}=0.
\end{equation*}
\end{tcolorbox}
\tiny
  \begin{thebibliography}{1}

\bibitem{albrecher2021blockchain}
H.~Albrecher, D.~Finger, and P.-O. Goffard, ``Blockchain mining in pools:
  Analyzing the trade-off between profitability and ruin,'' 2021.

\end{thebibliography}
\end{frame}
\begin{frame}[allowframebreaks]{Sketch of the Proof}
\scriptsize
We condition upon what happen during the time interval $(0,h)$. Four possibilities
\begin{itemize}
  \item[(i)] $T>h$ and no jump during $(0,h)$
  \item[(ii)] $T<h$ and no jump over $(0,T)$
  \item[(iii)] An upward jump in the interval $(0,h)$
  \item[(iv)] A downward jump in the interval $(0,h)$
\end{itemize}
  \begin{eqnarray*}\label{neu0}
      \w{V}(u,t)&=& e^{-(\frac{1}{t}+\lambda+\mu^\ast)h}\w{V}(u,t) + \frac{1}{t}\int_0^h e^{-{s}/{t}}e^{-(\lambda +\mu^\ast) s} u\,ds\\
      & +& \lambda\int_0^he^{-\lambda s} e^{-({1}/{t}+\mu^\ast) s} \int_0^\infty\w{V}(u+x,t)\,dF_{B}(x)\,ds\\
      &  +&\mu^\ast \int_0^he^{-\mu^\ast s} e^{-({1}/{t}+\lambda) s}\int_0^u \w{V}(u-y,t) \,dF_W(y)\,ds.
  \end{eqnarray*}
  Differentiating with respect to $h$ and letting $h\rightarrow 0$ yields the following integral equation
  \begin{equation} \label{inteq}
    \lambda\int_0^\infty\w{V}(u+x,t)\,dF_{B}(x)-(\lambda+\mu^\ast+{1}/{t})\w{V}(u,t)+\mu^\ast\int_0^u \w{V}(u-y,t) \,dF_W(y)+{u}/{t}=0,\quad u\ge 0,
  \end{equation}
  with boundary conditions $\w{V}(u,t)=0$ for all $u<0$ and $0\leq\w{V}(u,t)\leq u+(\lambda b^\ast - \mu^\ast w)t$. Let us plug in the ansatz
  $$
  Ce^{-ru}+d_1u+d_0
  $$
  \begin{itemize}
    \item Comparing the terms in $e^{-r u}$ gives and equation for $r$
    $$
    -(t^{-1}+\lambda+\mu^\ast)+\lambda(1+b^\ast r)^{-1}+\mu^\ast(1-wr)^{-1}=0
    $$
    of which only the positive solution $R>0$ is valid due to the boundary conditions.
    \item Comparing the terms in $u$ yields $d_1 = 1$
    \item Comparing the terms in $1$ yields
    $$
    d_0 = t(\lambda b^\ast-\mu^\ast w)
    $$
    \item Comparing the terms in $e^{-u/w}$
    $$
    C = (1 - Rw)[w-t(\lambda b^\ast-\mu^\ast w)]
    $$
  \end{itemize}
\end{frame}
\begin{frame}{Problem caused by mining}
\begin{itemize}
  \item $R\&D$ arm race, consuming a lot of energy and generating large amounts of e-waste
\tiny
\begin{thebibliography}{1}

\bibitem{bertucci2020mean}
C.~Bertucci, L.~Bertucci, J.-M. Lasry, and P.-L. Lions, ``Mean field game
  approach to bitcoin mining,'' 2020.

\bibitem{Alsabah2018}
H.~Alsabah and A.~Capponi, ``Bitcoin mining arms race: R{\&}d with
  spillovers,'' {\em {SSRN} Electronic Journal}, 2018.

\end{thebibliography}
\end{itemize}
\begin{itemize}
  \item \normalsize A threat on centralization?
\tiny
\begin{thebibliography}{1}

\bibitem{Cong2020}
L.~W. Cong, Z.~He, and J.~Li, ``Decentralized mining in centralized pools,''
  {\em The Review of Financial Studies}, vol.~34, pp.~1191--1235, apr 2020.

\bibitem{li2019mean}
Z.~Li, A.~M. Reppen, and R.~Sircar, ``A mean field games model for
  cryptocurrency mining,'' 2019.

\end{thebibliography}
\end{itemize}
\end{frame}

\begin{frame}{Blockwithholding strategies}
\begin{center}
\begin{tikzpicture}[-, >=stealth', auto, semithick, node distance=1cm]

% \tikzstyle{block} = [rectangle, draw, fill=blue!20,
%     text width=5em, text centered, rounded corners]
\tikzstyle{unconfirmed block}=[rectangle, fill=white, draw=black,dashed, thick,text=black,scale=1]
\tikzstyle{phantom block}=[rectangle, fill=white,draw=white,thick,text=black,scale=1]
\tikzstyle{confirmed block}=[rectangle, fill=black,draw=black,thick,text=black,scale=1]
\tikzstyle{bad block unconfirmed}=[rectangle, fill=white,draw=tublue,very thick, text=black,scale=1]
\tikzstyle{bad block confirmed}=[rectangle, fill=tublue, text=black,scale=1]
\node[confirmed block]    (1){};
\node[phantom block]    (2)[right of=1] {};
% \node[phantom block]    (3)[below of=1] {};
\pause
\node[bad block unconfirmed] (4)[below of=2] {};
\draw[-,dashed,thick,tublue] (1) |- node[near start,above] {} (4);
% \path
% (1) edge[dashed, tublue, thick, left] node{} (3);
% (3) edge[dashed, tublue, thick, left] node{} (4);
\pause
\node[bad block unconfirmed]    (5)[right of=4] {};
\node[bad block unconfirmed]    (6)[right of=5] {};
\path
(4) edge[dashed, tublue, thick, left]     node{}     (5)
(5) edge[dashed, tublue, thick, left]     node{}     (6);
\pause
\node[confirmed block] (7)[right of =1]{};
\path
(1) edge[-, black, thick, left]     node{}     (7);
\pause
\node[bad block confirmed]    (8)[below of=2] {};
\draw[-,thick,tublue] (1) |- node[near start,above] {} (8);
\pause
\node[confirmed block] (9)[right of =7]{};
\path
(7) edge[-, black, thick, left]     node{}     (9);
\pause
\node[bad block confirmed]    (10)[right of=4] {};
\node[bad block confirmed]    (11)[right of=5] {};
\node[right of=11] {\scriptsize$3\cdot b$ (LCR) };
\node[right of=9] {\scriptsize$0$};
\path
(4) edge[-, tublue, thick, left]     node{}     (10)
(4) edge[-, tublue, thick, left]     node{}     (11);
\end{tikzpicture}
\end{center}
\pause
\scriptsize
Why?
\pause
\begin{itemize}
  \item Relative revenue greater than their fair share
  \item Honest miners waste resources
  \begin{itemize}
    \scriptsize
    \item[$\hookrightarrow$] Honest miner might quit making malicious miners more powerful
  \end{itemize}
  \item Slow down the pace of block arrivals
  \begin{itemize}
    \scriptsize
    \item[$\hookrightarrow$] Downward adjustment of the cryptopuzzle difficulty
  \end{itemize}
\end{itemize}
\begin{tcolorbox}[enhanced,drop shadow, title=Difficulty adjustments]
The cryptopuzzle difficulty is adjusted every $2,016$ blocks to ensure $1$ block every ten minutes on average.
\end{tcolorbox}
\tiny
\begin{thebibliography}{1}
  \bibitem{Eyal2014}
I.~Eyal and E.~G. Sirer, ``Majority is not enough: Bitcoin mining is
  vulnerable,'' in {\em Financial Cryptography and Data Security},
  pp.~436--454, Springer Berlin Heidelberg, 2014.
\end{thebibliography}
\end{frame}
\begin{frame}{Tied selfish mining}
\begin{columns}
\begin{column}{0.5\textwidth}
\begin{center}
\begin{tikzpicture}[-, >=stealth', auto, semithick, node distance=1cm]

\tikzstyle{unconfirmed block}=[rectangle, fill=white,draw=black, thick,text=black,scale=1]
\tikzstyle{phantom block}=[rectangle, fill=white,draw=white,thick,text=black,scale=1]
\tikzstyle{confirmed block}=[rectangle, fill=black,draw=black,thick,text=black,scale=1]
\tikzstyle{bad block unconfirmed}=[rectangle, fill=white,draw=tublue,very thick, text=black,scale=1]
\tikzstyle{bad block confirmed}=[rectangle, fill=tublue, text=black,scale=1]
\node[confirmed block]    (1){};
\node[phantom block]    (2)[right of=1] {};
% \node[phantom block]    (3)[below of=1] {};
\node[bad block unconfirmed] (3)[below of=2] {};
\draw[-,dashed,thick,tublue] (1) |- node[near start,above] {} (3);
\pause
\node[confirmed block] (4)[right of=1]{};
\path
(1) edge[-, black, thick, left]   node{}(4);
\pause
\node[bad block confirmed] (5)[below of=2] {};
\draw[-,thick,tublue] (1) |- node[near start,above] {} (5);
\pause
\node[unconfirmed block] (6)[right of=4] {};

\end{tikzpicture}
\end{center}
\end{column}
\begin{column}{0.5\textwidth}
\begin{tikzpicture}[-, >=stealth', auto, semithick, node distance=1cm]
\tikzstyle{unconfirmed block}=[rectangle, fill=white,draw=black, thick,text=black,scale=1]
\tikzstyle{phantom block}=[rectangle, fill=white,draw=white,thick,text=black,scale=1]
\tikzstyle{confirmed block}=[rectangle, fill=black,draw=black,thick,text=black,scale=1]
\tikzstyle{bad block unconfirmed}=[rectangle, fill=white,draw=tublue,thick, text=black,scale=1]
\tikzstyle{bad block confirmed}=[rectangle, fill=tublue,draw=tublue,thick, text=black,scale=1]
\node[confirmed block]    (1){};
\node[phantom block]    (2)[right of=1] {};
\node[confirmed block] (4)[right of=1]{};
\path
(1) edge[-, black, thick, left]   node{}(4);
\node[bad block confirmed] (5)[below of=2] {};
\draw[-,thick,tublue] (1) |- node[near start,above] {} (5);
\node[confirmed block] (6)[right of=4] {};
\path
(2) edge[-, black, thick, left]   node{}(6);
\node[right of=6] {\scriptsize$2\cdot b$  };
\node[right of=5] {\scriptsize$0$};
\end{tikzpicture}
\pause
\newline
\newline
\begin{tikzpicture}[-, >=stealth', auto, semithick, node distance=1cm]
\tikzstyle{unconfirmed block}=[rectangle, fill=white,draw=black, thick,text=black,scale=1]
\tikzstyle{phantom block}=[rectangle, fill=white,draw=white,thick,text=black,scale=1]
\tikzstyle{confirmed block}=[rectangle, fill=black,draw=black,thick,text=black,scale=1]
\tikzstyle{bad block unconfirmed}=[rectangle, fill=white,draw=tublue,thick, text=black,scale=1]
\tikzstyle{bad block confirmed}=[rectangle, fill=tublue,draw=tublue,thick, text=black,scale=1]
\node[confirmed block]    (1){};
\node[phantom block]    (2)[right of=1] {};
\node[confirmed block] (4)[right of=1]{};
\path
(1) edge[-, black, thick, left]   node{}(4);
\node[bad block confirmed] (5)[below of=2] {};
\draw[-,thick,tublue] (1) |- node[near start,above] {} (5);
\node[confirmed block] (6)[right of=5] {};
\path
(5) edge[-, tublue, thick, left]   node{}(6);
\node[right of=4] {\scriptsize$0$  };
\node[right of=6] {\scriptsize$b$ $\&$ $b$};
\end{tikzpicture}
\pause
\newline
\newline
\begin{tikzpicture}[-, >=stealth', auto, semithick, node distance=1cm]
\tikzstyle{unconfirmed block}=[rectangle, fill=white,draw=black, thick,text=black,scale=1]
\tikzstyle{phantom block}=[rectangle, fill=white,draw=white,thick,text=black,scale=1]
\tikzstyle{confirmed block}=[rectangle, fill=black,draw=black,thick,text=black,scale=1]
\tikzstyle{bad block unconfirmed}=[rectangle, fill=white,draw=tublue,thick, text=black,scale=1]
\tikzstyle{bad block confirmed}=[rectangle, fill=tublue,draw=tublue,thick, text=black,scale=1]
\node[confirmed block]    (1){};
\node[phantom block]    (2)[right of=1] {};
\node[confirmed block] (4)[right of=1]{};
\path
(1) edge[-, black, thick, left]   node{}(4);
\node[bad block confirmed] (5)[below of=2] {};
\draw[-,thick,tublue] (1) |- node[near start,above] {} (5);
\node[bad block confirmed] (6)[right of=5] {};
\path
(5) edge[-, tublue, thick, left]   node{}(6);
\node[right of=4] {\scriptsize$0$  };
\node[right of=6] {\scriptsize$2\cdot b$};
\end{tikzpicture}

\end{column}
% snzj
% \pause
\end{columns}
\pause
\scriptsize
\begin{tcolorbox}[enhanced,drop shadow, title=Fact]
The outcome of the fork when the honest miners find the subsequent block depends on the connectivity parameter $q\in(0,1)$ of the malicious nodes.
\end{tcolorbox}
\end{frame}
\begin{frame}{Markov model}
\scriptsize
\begin{itemize}
\item Let $(Z_n)_{n\geq0}$ be the number of blocks in the selfish miner's buffer with state space $\{0, 0^\ast, 1\}$.

\item The transition graph is given by
\begin{center}
\begin{tikzpicture}[->, >=stealth', auto, semithick, node distance=2cm]
\tikzstyle{every state}=[fill=white,draw=black,thick,text=black,scale=0.8]
\node[state]    (1)                     {\scriptsize$0$};
\node[state]    (2)[right of=1]         {\scriptsize$1$};
\node[state]    (3)[above of=2]         {\scriptsize$0^{\ast}$};
\path
(1) edge[loop left]     node{\scriptsize$1-p$}        (1)
    edge[bend left]     node{\scriptsize$p$}          (2)
(2) edge[bend left]      node{\scriptsize$p$}         (1)
    edge[bend right]      node{\scriptsize$1-p$}      (3)
(3) edge[bend right, above]      node{\scriptsize$1$}         (1);
\end{tikzpicture}
\end{center}
\item The reward collecting process is also Markovian as
\begin{equation*}
f\left[Z_{n-1}, \xi_n,\zeta_{n}\right] = \begin{cases}
0,&\text{ if } Z_{n-1} =0,\\
0,&\text{ if } Z_{n-1} =1\text{ }\&\text{ }\xi_{n} =0,\\
2,&\text{ if } Z_{n-1} =1\text{ }\&\text{ }\xi_{n} =1,\\
0,&\text{ if } Z_{n-1} =0^\ast \text{ }\&\text{ }\xi_{n} = 0\text{ }\&\text{ }\zeta_{n} = 0,\\
1,&\text{ if } Z_{n-1} =0^\ast \text{ }\&\text{ }\xi_{n} = 0\text{ }\&\text{ }\zeta_{n} = 1,\\
2,&\text{ if }Z_{n-1} = 0^\ast \text{ }\&\text{ }\xi_{n} = 1.\\
\end{cases}
\end{equation*}
where $\xi_n\sim\text{Ber}(p)$ and $\zeta_n\sim\text{Ber}(q)$
\end{itemize}
\end{frame}
\begin{frame}{Wealth of a selfish miner}
\scriptsize
The wealth process of a selfish miner is given by
$$
R_t = u - c\cdot t +b\cdot\sum_{n=1}^{N_t} f(Z_k,\xi_n,\zeta_n ).
$$
where $N_t$ is a Poisson process with intensity $\lambda$ that corresponds to the arrival of blocks in the blockchain.
\begin{itemize}
  \item The net profit condition reads as
  $$
  \frac{b}{t}\mathbb{E}\left[\sum_{n=1}^{N_t} f(Z_k,\xi_n,\zeta_n )\right] > c
  $$
  \item Once stationarity is reached we have
  $$
\P(Z_\infty = 0)=\frac{1}{1+2p-p^2},\text{ }\P(Z_\infty = 1)=\frac{p}{1+2p-p^2},\text{ and }\P(Z_\infty = 0^{\ast})=\frac{p(1-p)}{1+2p-p^2},
$$
and the net profit condition correspondingly reads
\begin{equation*}
b\lambda\frac{qp(1-p)^2 + 4p^2-2p^3}{1+2p-p^2} - c>0.
\end{equation*}
\end{itemize}
\end{frame}
\begin{frame}{Expected profit of a selfish miner}
\scriptsize
Define
\begin{equation*}
\w{\psi}_z(u,t)\equiv \E(\psi_z(u,T)) = \mathbb{E}\left(\psi(u,T)\Big \rvert Z_0 = z\right) \text{ and }\w{V}_z(u,t)\equiv \E(V_z(u,T)) = \mathbb{E}\left(R_T\mathbb{I}_{\tau_u>T}\Big \rvert Z_0 = z\right)
\end{equation*}
\begin{tcolorbox}[enhanced,drop shadow, title=Theorem]
For any $u\ge 0$, the ruin probability and expected profit of a selfish miner are given by
\begin{equation*}\label{ruin_selfish_app}
\w{\psi}_0(u,t) =
{\it C_1}\,{{\rm e}^{\rho_1\,u}}+{{\rm e}^{\rho_2\,u}} \left[ {\it C_2}\,
\cos \left( \rho_3\,u \right) +{\it C_3}\,\sin \left( \rho_3\,u \right)\right],
\end{equation*}
and
\begin{equation*}
\w{V}_0(u,t)={\it A_1}\,{{\rm e}^{\rho_1\,u}}+{{\rm e}^{\rho_2\,u}} \left[ {\it A_2}\,
\cos \left( \rho_3\,u \right) +{\it A_3}\,\sin \left( \rho_3\,u \right)\right] +u+C,\label{thisone}
\end{equation*}
\end{tcolorbox}
\tiny
  \begin{thebibliography}{1}

\bibitem{albrecher:hal-02649025}
H.~Albrecher and P.-O. Goffard, ``{On the profitability of selfish blockchain
  mining under consideration of ruin},'' {\em To appear in Operations
  Research}, May 2021.
\newblock \url{https://arxiv.org/abs/2010.12577}.

\bibitem{grunspan2019profitability}
C.~Grunspan and R.~Pérez-Marco, ``On profitability of selfish mining,'' 2019.
\end{thebibliography}
\end{frame}
\begin{frame}{Conclusion and perspectives}
\begin{itemize}
  \item Selfish mining entails a waste of resources for everybody
  \item Including a difficulty adjustment can make it strategic
  \item Possible extensions
  \begin{enumerate}
  \item Consider stochastic jumps
  \item Consider the actual selfish mining strategy
  \item Consider generalization of the selfish mining strategy
  \tiny
  \begin{thebibliography}{1}

\bibitem{Sapirshtein2017}
A.~Sapirshtein, Y.~Sompolinsky, and A.~Zohar, ``Optimal selfish mining
  strategies in bitcoin,'' in {\em Financial Cryptography and Data Security},
  pp.~515--532, Springer Berlin Heidelberg, 2017.

\end{thebibliography}
\begin{itemize}
  \item[$\hookrightarrow$] Stochastic control problem!
\end{itemize}
\item \small Better understanding of the connectivity parameter $q$
\tiny
\begin{thebibliography}{1}

\bibitem{GoHoKrTa16}
J.~G{\"o}bel, H.~P. Keeler, A.~E. Krzesinski, and P.~G. Taylor, ``Bitcoin
  blockchain dynamics: The selfish-mine strategy in the presence of propagation
  delay,'' {\em Performance Evaluation}, vol.~104, pp.~23--41, 2016.

\end{thebibliography}
\begin{itemize}
  \item[$\hookrightarrow$] Graph theory!
\end{itemize}
\end{enumerate}
\end{itemize}
\end{frame}

\end{document}


\section{Trajectory Planning (Catherine)}

This component is divided into two subsections:
\begin{enumerate*}[label=\thesection.\arabic*]
\item Trajectory Planner for robot arm trajectory planning, and
\item Trajectory Executor for robot arm trajectory execution.
\end{enumerate*}

\subsection{Trajectory Planner}

During execution, the task planner requests the path planner to create trajectory plans for one or more robot arms. The planner aims to find a plan that (i) each arm starts at its initial configuration, and (ii) each arm ends with each robot end effector within a certain radius from the final desired workspace position. If the planner finds a plan, it returns the joint-space trajectory for each arm. If the planning exceeds the time limit, then the planner aborts and returns no trajectories.

There are a variety of path planning algorithms developed in the community~\cite{DBLP:books/daglib/0016830} and some algorithms are adapted for finding robot arm trajectories.
Researchers have proposed sampling-based approaches with probabilistic completeness such as the Rapidly-Exploring Random Tree (RRT) algorithm ~\cite{VahrenkampBAKD09} to find trajectories for robot arms. Others have used Probabilistic RoadMaps (PRM) that work with high-dimensional spaces~\cite{KavrakiSLO96} but the algorithm requires pre-computation of the roadmap and no dynamic obstacles in the environment. In this project, we will not conduct pre-processing and the other arms can become obstacles so we are using RRT to find trajectories for the robot arms.

First, we plan to try two different RRT approaches and compare their performance. With RRT, there are still multiple ways to generate a trajectory plan.
One of them is to generate trajectory plan synchronously.
For example, if there are four arms available for a task, or two Baxters, then the planning could be synchronous, i.e, we plan all the arms at the same time and each node in RRT stores the joint information of the four arms. With each arm having 7 degrees of freedom (DoF), a synchronous planning has up to 28 degrees of freedom.
With this approach, assuming the workspace has no other obstacles, collision avoidance with the other arms is taken care of during the planning phase so it is unnecessary during trajectory execution.
The trade off of synchronous planning is that one arm may wait for the others even though its trajectory is found.

Alternatively, another way would be to first create a plan each arm separately and assign priorities to each arm. An arm then replans only when its trajectory intersects with the plan of another arm with a higher priority. Compared with the synchronous approach, each planning contains 7 degrees of freedom but re-plannings of trajectory can go up to (n-1) times, with n being the number of arms.

Second, we plan to create our own version of RRT planner and also utilize off-the-shelf library with RRT such as the Open Motion Planning library (OMPL)~\cite{sucan2012the-open-motion-planning-library} to find out the one with better performance.
Compared with creating our own RRT planner, OMPL has lots of planning algorithms available, but most examples of OMPL work with single robot or arm and planning for multiple arms simultaneously with OMPL may be unfeasible. We plan to learn more about OMPL and then decide if we are creating our own RRT planner or we are using OMPL to build our planner.

Finally, RRT is only a template for planning and we need to complete the template with ways to propagate a trajectory and smoothen the resulting trajectory.
During the planning phrase, we plan to optimize the final trajectory by reducing the difference in joint angles between two nodes in the RRT tree. We use inverse kinematics find robot joint angles given a desired location of the end effector.

%To conduct a path planning of the robot arms, the planner takes in:

%\begin{itemize}
%\item the number of arms we are planning,
%\item the starting joint configurations of each arm, and
%\item the final workspace positions of robot end effectors.
%\end{itemize}

\subsection{Trajectory Executor}

Besides a trajectory planner, the person in charge of this component also creates a trajectory executor that executes any given trajectory.
Once the task planner receives a plan, it can invoke the trajectory executor to execute the path. The executor takes in a joint-space trajectory and notifies the task planner when it finishes the execution. The task planner then invokes planning by the action planner in the next section to conduct fine and accurate objects manipulation.


\documentclass[12pt]{article}

\setlength{\parindent}{0pt}
\setlength{\parskip}{2mm}

\usepackage{geometry}
 \geometry{
 letterpaper, left=20mm, right=20mm,  top=20mm,
 }
\usepackage{graphicx}
\graphicspath{ {graphics/} }
\usepackage{amssymb}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\title{RFC 1: Collisions in Delay-Based ID Encoding Protocol}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\author{
	Margot Maxwell \and
	Lizzy Schoen \and
	Noah Strong \and
	Chloe Yugawa
}

\date{v1.2 -- \today}

\begin{document}

\maketitle

\tableofcontents{}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Introduction}

The protocol proposed for this project encodes a unique identification number
in the transmitted signal by the delay between two consecutive pings.
While this method is easy to implement in hardware, and works well in the case
of only a signal transmitter, the addition of multiple transmitters within range
of a receiver brings about the potential for collisions between different
signals.
In some cases, the collisions may be undetectable, leading to incorrect
reporting of nearby crab IDs.
Completely solving this problem will require a change to the underlying
protocol.
However, the likelihood of such collisions may be low enough that we can move
forward with this known flaw in the protocol.

\section{Original Protocol}

In the current iteration of our detection and identification protocol, every
transmitter will transmit at the exact same frequency, somewhere around
40kHz. This is ideal from a hardware perspective, as the piezoelectric
equipment can be tuned to work on a single frequency with a high degree of
accuracy.

Every transmitter will periodically send out two quick ``pings,'' each separated
by some delay $d$. The value of $d$ will encode the ID of the transmitter.
For example, $d=42$ms may correspond to ID 30, while $d=50.5$ms may
correspond to an ID of 38.
Note that these numbers are only for illustration purposes.
Because the receiving hardware can easily detect the two pings, it can measure
the value of $d$ by calculating the time difference between the rising edges
of the consecutive signals. See Figure 1 for an illustration.

\begin{figure}[h]
\centering
\includegraphics[scale=0.7]{singleTx}

\caption{A single transmitter ($Tx1$), the input received by the receiver
($Sum$), and the calculated delay $d$ based on the time measured between
the rising edges of the two pings from $Tx1$.}
\end{figure}

Each transmission of an ID by a transmitter (that is, the sequence of a
ping, a delay, and another ping) will happen regularly around some average
interval.
Because there is no synchronization between transmitters, the interval
between each broadcast will vary randomly within a given range.
For example, the delay may be 30 seconds, $\pm$5 seconds, with the random
variation recalculated after every broadcast.

The motivation behind the randomly-varying schedule is to decrease the
likelihood of simultaneous transmissions by two different receivers.
However, the random interval only functions to reduce the likelihood of
two \emph{consecutive} overlapping transmissions.
Without an inter-receiver collision-detection solution, there will always
be the possibility that two transmissions overlap.

\section{Possibility for Collisions}

As discussed above,
when two transmitters are present in the receiving range, and there is no
synchronization between the two (i.e. they may transmit their IDs at any
time, regardless of when the other transmits), it is possible for the two
transmissions to be broadcast at similar times, thereby overlapping.
The signals may overlap in countless different ways depending on when
both transmissions start and where the transmitters are in relation to
each other and to the receiver.

In some cases, collisions may cause the data to be some so skewed that it will
be easy to detect and throw away. However, in a more likely and more dangerous
situation, the overlap of data will lead to inaccurate results and be extremely
difficult to detect.

\subsection{Example Scenarios}

Below are a few possible scenarios that may occur in practice or in testing
environments. Note that this is by no means an exhaustive list, but instead
a selection of cases chosen to demonstrate potential issues.

We'll define some notation for the sake of convenience and clarity.
If $Tx1$ is a transmitter, then $d_1$ is the delay time between
the two pings for $Tx1$; that is, $d_1$ encodes the unique ID for $Tx1$.
We'll also use $B_1$ to denote the first ping from $Tx1$
(the {\bf B}eginning of the encoding) and $E_1$ to denote the second
({\bf E}nd of the encoding) ping.

\subsubsection{Close Proximity, Similar Start}

{\bf Situation:} Two transmitters in close proximity to each other transmit at
very nearly the same time.
Their transmissions line up so that the first ping from $Tx2$ starts as the
first ping from $Tx1$ is broadcasting.
If the delay times happen to be very similar for the two transmitters,
it is possible that the same effect is observed in reverse on the ending
pings. That is, the second ping for $Tx2$ begins just before the second ping
for $Tx1$. See Figure 2 for an illustration.

{\bf Potential Effect:}
Should this happen, the receiver will register two pings, just as it would if
only one transmitter broadcasts. However, the measured delay
$d_{measured}$ will not equal $d_1$ or $d_2$.
Thus the software will report the ID corresponding to $d_{measured}$, and
not the ID of either of the transmitters actually broadcasting. Worse still,
there is no way to detect when this happens.

\begin{figure}[h]
	\centering
		\includegraphics[scale=0.7]{collision1}

		\caption{An example collision. The computed delay $d$ is
		measured as the time difference between the rising edge of
		$Tx1$'s first ping and $Tx2$'s second ping.}
\end{figure}

\subsubsection{Close Proximity, Offset Broadcasts}

{\bf Situation:} As in the previous example, suppose there are two transmitters
in close proximity to each other.
However, in this situation, suppose the two transmissions are broadcast at
similar times so that they are interleaved.
That is, the receiver will see $B_1$, $B_2$, $E_1$, $E_2$, in that order.
See Figure 2 for an illustration.

{\bf Potential Effect:}
In this case, the receiver will detect two different delay times, which may
seem normal. However, these delays are once again wrong -- they do not
correspond to any transmitter actually transmitting.
The software will then report that there are two signals coming from a
specific direction, but the IDs that it thinks these correspond to will
be incorrect.
As in the previous example, there is no way to detect when this happens, so the
software would unknowingly present incorrect information.

\begin{figure}[h]
	\centering
		\includegraphics[scale=0.7]{collision2}

		\caption{Another example collision. Note that in this situation,
		two distinct delays are measured. While it is possible for them
		to both correlate to valid IDs, neither delay matches the delays
		actually encoded by $Tx1$ or $Tx2$.}
\end{figure}

\subsubsection{A Series of Overlapping Broadcasts}

In an extreme case, it may be possible for multiple transmitters to all begin
broadcasting at very similar times such that all of their pings overlap and are
registered as a single (extremely long) ping.
For instance, if $n$ transmitters send out pings perfectly sequentially,
it is conceivable
that the receiver receives $B_1$, $B_2$, $\dots$, $B_n$ in order with so little
temporal separation that no falling edges are registered by the receiving
hardware.
In other words, the receiver hears one long, solid tone, as opposed to a series
of quick pings. It is theoretically possible that this single perceived tone
is so long that the ending pings of one or more transmitters may be hidden.

This is an extreme case, but is nonetheless a possibility given significant
transmitter density in the receiving range, sufficiently long pings, and
sufficiently low delay $d_n$ values for the transmitters in play.

\subsubsection{Mutually Distant Transmitters}

In general, though the above situations are quite possible, it is more likely
that two or more transmitters in the receiving range will be in different
directions from the receiving station.
When two or more transmitters that are in different areas around the receiver
broadcast at similar times, the overlaps will interfere in even more complex
ways.
Such scenarios are much more difficult to illustrate, but suffice it to say
that they will also cause problems with invalid or confusing data.
As before, some collisions can be detected and compensated for with a
sufficiently complex algorithm, but not all cases are solvable with the current
protocol.

\section{Potential Solutions}

Some early solutions that do not entirely change the original protocol have
been proposed. They are discussed briefly below. This section may be expanded
in the future as we discuss more options.

\subsection{Use Two Frequencies To Differentiate Pings}

One proposed solution is for every transmitter to have the ability to broadcast
at two different frequencies, and use one for the first ping and another for
the second. For example, the first ping may be 40 kHz and the second one could
be 42 kHz.

{\bf Pros:}
\begin{itemize}
	\item With some added computation, we could compensate for some overlaps,
	such as the one described in example 3.1.2.
	Though some extreme cases, such as 3.1.1, would still lead to undetected
	incorrect results, the majority of overlap cases could be fixed.
\end{itemize}

{\bf Cons:}
\begin{itemize}
	\item This method would not scale to $>2$ transmitters overlapping.
		Situations analogous to 3.1.2 but with 3 or more transmitters would
		still cause problems.
		However, giving our initial estimates of crab densities, this may be
		highly unlikely.
\end{itemize}

\subsection{Attempt to Detect Anomalies Through Statistical Reasoning}

Another proposal is to make the software smart enough to remember where a
signal comes from every time a transmission is received. It keeps track of
where it thinks all the known transmitters are and compares that data with
incoming data whenever a transmitter is detected.

Further investigation into this suggestion is needed.
However, one initial problem with that is that in order for such a technique
to be effective, the software must know the location and movement of the
receiver (via GPS or a similar technology).

\subsection{Detect Falling Edges of Transmissions}

Our original protocol assumes that the receiving system only detects the rising
edges of every transmission. Adding the ability to detect the falling edges may
help counteract some of the aforementioned problems. Specifically, it would
potentially allow the system to detect when two nearly-simultaneous (though
not truly simultaneous) transmissions overlap, as this technique would give
the system
the ability to detect when a ping lasts longer than the expected ping length.
Unfortunately, such scenarios are only a small subset of the problems identified
above.

Additionally, adding this ability may be somewhat difficult from a hardware
perspective. It would require precise tuning of the hardware integrator, which
could be difficult since the effective amplitude of each ping can vary based on
a number of factors (including transmitter strength, aquatic conditions, objects
interfering with the signal, and more).
It was also mentioned at one point that communicating a falling-edge event to
the receiving computer is not entirely simple.

\subsection{Adjust Ping Length ($p$) Relative to Delay ($d$) Time}

In our original protocol, the duration of every transmitter's ping was fixed.
This solution proposes that we instead allow the ping's duration to vary
on a per-transmitter basis.
The ping length should be a function of the delay time, and therefore also a
function of the unique ID,
so that every unique ID has an associated unique ping duration $p$ and unique
delay time $d$.
For example, we might require that $p=\frac{1}{2}d$; that is, every ping
is half as long as the delay between rising edges of ping pairs.

This method creates some redundancy be encoding the unique ID up to three times
in a single transmission
(the first ping's duration, the delay length, and the second ping's duration).
Though this redundancy doesn't provide us any improved accuracy or detection,
it would allow the software to reliably determine whenever a collision occurs.
A further discussion of why this method allow for collision detection is
forthcoming.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% TODO - discuss examples, explanation, etc.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

This solution does have some potential difficulties associated with it.
The biggest is that we would need well-tuned detection hardware so that we can
reliably note the rising a falling edges of every signal.
In practice, the software should probably compensate for some inaccuracy here
depending on how successful our tuning efforts are.
For example, weaker signals may not register strongly enough for the hardware
integrator to report accurate rising and falling edges.
Fortunately, as Dr. Lund points out, we could instead opt to have the system
compare the ping lengths across the receiving hydrophones.
Regardless of signal strength, transmitter distance, or other factors that
may cause the measurement of the ping duration to differ from the actual
ping duration, the ping duration measured by all four receivers should be
nearly identical. That is, the signal won't decay by a significant amount
in the short travel from one end of the receiving station to the other.
If the measured ping lengths differ between any of the hydrophones,
we can be confident that a collision occurred.

\section{Statistical Probability of Collisions}

For a discussion of the statistical likelihood of collisions occurring, see
the {\em RFC Stats} document written by CY.

\section{Discussion}

All involved parties seem to agree that this problem is worth some attention,
despite its expected low likelihood.
We will move forward with implementing a falling-edge based solution
related to the ideas proposed in section 4.4.
Specific implementation details will be written up in a new document as they
are decided on.

\end{document}


% !TEX root = ../00_thesis.tex

\section{System Model}
\label{sec:problem}

Let \flowset be the set of real-time message \emph{flows} in the system.
The message release of each flow is \emph{sporadic with jitter}; \ie each flow $\flowi = (\flowsrci,\flowdsti,\periodi,\jitteri,\deadlinei)$ is defined by a \emph{source application} running on \emph{source node} \flowsrci that \emph{releases} messages with a \emph{minimum message interval} \periodi and \emph{jitter} \jitteri ($\jitteri < \periodi$), such that the time span of $n$ successive messages is never smaller than $(n-1)\times\periodi - \jitteri$ for any $n$. Every message released at $n_i^s$ should be delivered to the application running on \emph{destination node} \flowdsti within the  same \emph{relative end-to-end deadline}~$\deadlinei$.

The system model is illustrated in \cref{fig:DRP_sysmodel}: a set of \emph{nodes}~\nodeset exchange messages over a wireless multi-hop network; messages sent from a source node to a destination node are possibly relayed by multiple other nodes.
A logically global network manager, called the \emph{host}, arbitrates access to the network. Physically, the host may be one of the nodes.
The source and destination applications of a flow \flowi run on physically distributed nodes \flowsrci and \flowdsti.
Nodes can send to and receive messages from all other nodes in the system.

\begin{figure}
  \centering
  \includegraphics[scale=1]{stack_drp}
  \caption{System model of the \DRPLong (\DRP).
  \capt{A set~$\mathcal{N}$ of \DPP nodes are forming a wireless CPS.
  The communication processors (\CPs) run the \blink real-time protocol~\cite{zimmerling2017Blink} to exchange messages across a multi-hop wireless network.
  The \CPs forward and receive messages from their application processors (\APs) through \bolt~\cite{sutton2015Bolt}.
  \DRP is a global scheduler that arbitrates end-to-end communications between the \APs.
  On each \AP, the application tasks can be scheduled freely (\eg using a polling server, rate monotonic, \etc) as long as the resulting schedule satisfies the \DRP contracts~(\cref{sec:designDetailed}).
  The host is a (logically) global network manager which arbitrates the access to the shared wireless medium; \ie it runs the \blink and \DRP schedulers. Physically, one of the nodes plays the role of the host.}}
  \label{fig:DRP_sysmodel}
\end{figure}

\fakepar{Problem statement}
The problem is to design a wireless \CPS that fulfills all the requirements presented in \cref{sec:drp_intro} such that, for every message of every flow \flowi $\in \mathcal{F}$ released at the source node \flowsrci, if it is successfully transmitted by the wireless network, then it is delivered to the destination application running on node \flowdsti within the flow end-to-end deadline \deadlinei.

\squarepar{%}
  \fakepar{Application use case}
  Consider an acoustic wireless sensor network, such as those used to monitor permafrost in high alpine regions~\cite{weber2019decade,meyer2019IPSN}.
  Rock cracks are unpredictable events; however when one such event does happen, data must be collected and forwarded rapidly to a sink node for processing. For an early-warning system, it is crucial that this happens in real-time.
  Such an application perfectly matches our system model and motivates our problem statement.%
}