\documentclass[11pt]{article}

\def\shownotes{1}
\def\notesinmargins{0}

\usepackage{fullpage}

\usepackage{mathtools,color,xcolor,hyperref,graphicx,wrapfig,listings,array,xspace}

\ifnum\shownotes=1
\ifnum\notesinmargins=1
\newcommand{\authnote}[2]{\marginpar{\parbox{\marginparwidth}{\tiny %
  \textsf{#1 {\textcolor{blue}{notes: #2}}}}}%
  \textcolor{blue}{\textbf{\dag}}}
\else
\newcommand{\authnote}[2]{
  \textsf{#1 \textcolor{blue}{: #2}}}
\fi
\else
\newcommand{\authnote}[2]{}
\fi

\newcommand{\lnote}[1]{{\authnote{\textcolor{orange}{Leo notes}}{#1}}}
\newcommand{\knote}[1]{{\authnote{\textcolor{green}{kushti notes}}{#1}}}
\newcommand{\mnote}[1]{{\authnote{\textcolor{red}{Morphic}}{#1}}}
\newcommand{\dnote}[1]{{\authnote{\textcolor{brown}{Dima notes}}{#1}}}

\newcommand{\ret}{\mathsf{ret}}
\newcommand{\new}{\mathsf{new}}
\newcommand{\hnew}{h_\mathsf{new}}
\newcommand{\old}{\mathsf{old}}
\newcommand{\op}{\mathsf{op}}
\newcommand{\verifier}{\mathcal{V}}
\newcommand{\prover}{\mathcal{P}}
\newcommand{\key}{\mathsf{key}}
\newcommand{\nextkey}{\mathsf{nextKey}}
\newcommand{\node}{\mathsf{t}}
\newcommand{\parent}{\mathsf{p}}
\newcommand{\leaf}{\mathsf{f}}
\newcommand{\vl}{\mathsf{value}}
\newcommand{\balance}{\mathsf{balance}}
\newcommand{\lft}{\mathsf{left}}
\newcommand{\rgt}{\mathsf{right}}
\newcommand{\lbl}{\mathsf{label}}
\newcommand{\direction}{\mathsf{d}}
\newcommand{\oppositedirection}{\bar{\mathsf{d}}}
\newcommand{\found}{\mathsf{found}}
\newcommand{\mypar}[1]{\smallskip\noindent\textbf{#1.}\ \ \ }
\newcommand{\ignore}[1]{}

\newcommand{\langname}{ErgoScript\xspace}
\newcommand{\lst}[1]{\text{\lstinline[basicstyle={\ttfamily}]$#1$}}

\newcommand{\andnode}{\ensuremath{\mathsf{AND}}}
\newcommand{\ornode}{\ensuremath{\mathsf{OR}}}
\newcommand{\tnode}{\ensuremath{\mathsf{THRESHOLD}}}
\newcommand{\GF}{\ensuremath{\mathrm{GF}}}

\begin{document}

\title{\langname, a Cryptocurrency Scripting Language\\Supporting Noninteractive Zero-Knowledge Proofs}

\author{Ergo Developers}

\maketitle

\begin{abstract}
This paper describes \langname, a powerful and protocol-friendly scripting language for cryptocurrencies. Programs in \langname are used to specify the conditions under which currency can be spent. The language supports a type of non-interactive zero-knowledge proofs called $\Sigma$-protocols and is flexible enough to allow for ring-signatures, multisignatures, multiple currencies, atomic swaps, self-replicating scripts, and long-term computation.
\end{abstract}

\section{Introduction}
\subsection{Background}

Since its early days, Bitcoin~\cite{Nak08} has allowed more than simple money transfers between two public keys: its Bitcoin Script scripting language has allowed participants to specify conditions for how money could be spent. A program written in Bitcoin Script is attached to every transaction output (i.e., amount received); this program protects the transaction by determining how the transaction output can be used as an input to (i.e., spent in) a future transaction. The simplest condition is specified by a program that contains the recipient's public key and states that the money can be spent by creating a signature that verifies under this key.  However, more general conditions are allowed by more sophisticated programs.

The Bitcoin Script language is a primitive stack-based language without loops~\cite{bscript}. To spend an output protected by a program, a spending transaction must provide a program in the same language, and the concatenation of the two programs must evaluate to \emph{true}. The creator of the spending transaction can be viewed as a prover (for example, proving knowledge of the secret key by producing a signature), where the statement that needs to be proven is specified by the output that is being spent. Transaction validity is verified by evaluating programs. Bounded validation time is ensured by the absence of loops in the programming language and a maximum program size of 10 kilobytes. Even so, some denial-of-service attacks exploiting script validation time have appeared \cite{bitcoindos, fivehrs, ethattacks}. On the other hand, the deliberate simplicity of the programming language limits the kinds of contracts that can be created on the Bitcoin platform.

On other end of the generality spectrum, Ethereum allows for arbitrary Turing-complete programs~\cite{wood2014ethereum}. This approach requires charging for computation, in order to prevent denial-of-service attacks, because the running time of a Turing-complete program cannot, in general, be estimated without actually running the program. It is also needed in this case to have gas limit per block, otherwise, DoS is possible anyway, for example, a miner can do attack the network for free.

A variety of cryptocurrency languages have appeared. We do not survey them here, but refer the reader to Scilla~\cite{Scilla},
Simplicity~\cite{o2017simplicity}, Marlowe~\cite{seijas2018marlowe}, TypeCoin~\cite{crary2015peer}, and many other languages.

\subsection{Our Contribution: \langname}
In this paper we introduce a new language called \langname that is specifically designed to be friendly to cryptographic protocols and applications. \langname is considerably more powerful than Bitcoin Script. As \langname contains no unbounded looping or recursive constructs, individual scripts in \langname are not Turing-complete.  In fact, given a program in \langname, it is easy to obtain an estimate of its running time. However, because \langname allows for self-replication, \langname can be used to create Turing-complete processes in a blockchain, as shown in \cite{CKM18} (see also Section \ref{sec:self-replicating}).

\paragraph{Built-in $\Sigma$-protocols}

Our new language incorporates proving and verifying as first-class primitives, giving developers access to a subclass of cryptographic proof systems known as non-interactive $\Sigma$-protocols (pronounced ``sigma-protocols'').   Thus, a script protecting a transaction output can contain statements ($\Sigma$-statements) that need to be proven (by producing $\Sigma$-proofs) in order to spend the output.

Conceptually, $\Sigma$-proofs \cite{Cra96} are generalizations~\cite{CL06} of digital signatures.
In fact, Schnorr signature scheme~\cite{Sch91} (whose more recent version is popularly known as EdDSA \cite{BDLSY12,rfc8032}) is the canonical example of a $\Sigma$-proof: it proves that the recipient knows the discrete logarithm of the public key (the proof is attached to a specific message, such as a particular transaction, and thus becomes a signature on the message; all $\Sigma$-proofs described here are attached to specific messages). $\Sigma$-protocols exist for proving a variety of properties and, importantly for \langname, elementary $\Sigma$-protocols can be combined into more sophisticated ones using the techniques of \cite{CDS94}. For an introduction to $\Sigma$-protocols, we refer the reader to \cite{Dam10} and \cite[Chapter 6]{HL10}.

\langname provides two elementary $\Sigma$-protocols over a group of prime order (such as an elliptic curve), written here in multiplicative notation:
\begin{itemize}
\item A proof of knowledge of discrete logarithm with respect to a fixed group generator: given a group element $h$, the proof convinces a verifier that the prover knows $w$ such that $h=g^w$, where $g$ is the group generator (also known as base point), without revealing $w$. This is the same as a Schnorr signature with public key $h$.
\item A proof that of equality of discrete logarithms (i.e., a proof of a Diffie-Hellman tuple): given group elements $g_1, g_2, u_1, u_2$, the proof convinces a verifier that the prover knows $w$ such that $u_1=g_1^w$ and $u_2=g_2^w$, without revealing $w$
\end{itemize}

\langname also provides the ability to build more sophisticated $\Sigma$-protocols by using connectives $\andnode$, $\ornode$, and $\tnode$ (also known as $k$-out-of-$n$).
Crucially, the proof for an $\ornode$ and a $\tnode$ connective does not reveal which of the relevant values the prover knows: for example, in \langname a ring signature by public keys $h_1, \dots, h_n$ can be specified as an $\ornode$ of $\Sigma$-protocols for proving knowledge of discrete logarithms of $h_1, \dots, h_n$. The proof can be constructed with the knowledge of just one such discrete logarithm, and does not reveal which one was used in its construction.

Our implementation of these protocols is in Scala \cite{scala} and Java \cite{java}. The implementation was informed by SCAPI \cite{scapi}, but does not use SCAPI code. We use Bouncy Castle \cite{bouncycastle} for big integer and elliptic curve operations; the implementation of arithmetic in fields of characteristic 2 (for $\tnode$ connectives) is our own.

\paragraph{Rich context, enabling self-replication}
In addition to $\Sigma$-protocols, \langname allows for predicates over the state of the blockchain and the current transaction. These predicates can be combined, via Boolean connectives, with $\Sigma$-statements, and are used during transaction validation. The set of predicates is richer than in Bitcoin, but still lean in order to allow for efficient processing even by light clients. Like in Bitcoin, we allow the use of current height of the blockchain; unlike Bitcoin, we also allow the use of information contained in the spending transaction, such as inputs it is trying to spend and outputs it is trying to create. This feature enables self-replication and sophisticated (even Turing-complete) long-term script behaviour, as described in examples below.

\langname is statically typed (with compile-time type checking) functional
language with first-class lambda expressions, collection, tuple and optional
type values, it allows standard operations, such as integer arithmetic,
logical and comparison operations as well as operations on group elements and authenticated dictionaries.

\ignore{
    \paragraph{Running time estimation and safety checks}
    \lnote{someone should fill this in, because I know very little about it}
    See Section \ref{sec:safety} for more details.
}

\section{\langname Language Description}

The language syntax is a subset of Scala with the same meaning, and therefore many of the constructs are easy to read for those familiar with Scala.

Before we describe the language, let us fix some terminology. A \emph{box} (often called a ``coin'' in other literature) contains some amount (\emph{value}, measured in Ergo tokens) and is protected by a \emph{script} (boxes also contain additional information, such as other tokens; this information is described in detail in Section \ref{sec:box-registers}). A \emph{transaction} spends the value of boxes that are its \emph{inputs} (which are outputs of some earlier transaction) and produces boxes that are its \emph{outputs}. In a given transaction, the sum of the values of the inputs must equal the sum of the values of the outputs (as we describe below, the scripting language is rich enough to allow for payment transactions fees and for minting of new coins without violating this rule).

All the unspent transaction outputs (\emph{UTXO}) at a given time represent the value stored in the blockchain. A script for a box must evaluate to ``true'' when this box is used as an input to a transaction. This evaluation is helped by a \emph{proof} (for $\Sigma$-statements) and a \emph{context}, which are part of the transaction. The proof is produced by someone who knows the relevant secrets, such as secret keys; the context contains information about the spending transaction, such as details of its inputs and outputs, and the current state of the blockchain, such as the current height of the blockchain and last 10 block headers from the blockchain.

\subsection{$\Sigma$-Statements}
\label{sec:sigma-statements}

The simplest script allows the owner of a public key to spend an output box in a future transaction by issuing a signature with the corresponding secret key. If the variable \texttt{pk} holds the public key, then this script is specified simply as a string
\begin{verbatim}
        pk
\end{verbatim}

In order for the compiler to know what value the variable \texttt{pk} is referring to, the compiler needs to be supplied with an \emph{environment}, which, in this case, is a single-element map, mapping the string \texttt{"pk"} to the object holding the public key.\footnote{This map is an object in Scala, and is passed to the compiler as a parameter together with the script (which is passed in as a string) when the compiler is invoked from within Scala code. We defer the discussion of how to invoke the compiler outside of Scala code to another article.}
The value of public key is hardwired into the script at compile time, thus
\texttt{"pk"} can also be called \emph{named constant} to reflect the fact
that it cannot change. When the script is later evaluated (i.e., when the box
is used as a transaction input), a $\Sigma$-proof of knowledge of the
corresponding secret key must be supplied by the prover.

A slightly more complex script may allow either one of two people to spend an box. If Alice owns public key \texttt{pkA}  and Bob owns public key \texttt{pkB} (with corresponding secret key \texttt{skA} and \texttt{skB}), then the script that would allow either one of them to spend the box is
\begin{verbatim}
        pkA || pkB
\end{verbatim}
Again, \texttt{pkA} and \texttt{pkB} need to be mapped to public key objects by an environment map.
Note that Alice and Bob individually can construct the proof necessary to spend this box using just one of the two corresponding secret keys, and, by the zero-knowledge property of $\Sigma$-protocols, the proof will not reveal whether \texttt{skA} or \texttt{skB} was used. This construct is known as a \emph{ring} signature.

Naturally, this approach can be extended to more than two keys. If Carol's public and secret keys are \texttt{pkC} and \texttt{skC}, then a three-key ring signature can be similarly constructed as
\begin{verbatim}
        pkA || pkB || pkC
\end{verbatim}

For syntactic convenience, multiple keys can be placed into a collection, and \texttt{anyOf} operator can be used instead of \texttt{||}, as follows:
\begin{verbatim}
        anyOf (Coll (pkA, pkB, pkC))
\end{verbatim}

A conjunction is also possible: the script
\begin{verbatim}
        pkA && pkB
\end{verbatim}
requires Alice and Bob to use secret keys corresponding to \texttt{pkA} and \texttt{pkB} in order to spend the box. Note that Alice and Bob will have to communicate to produce the proof: separate signatures by Alice and Bob will not be sufficient (but Alice and Bob will not have to reveal their secret keys to each other; see Section~\ref{sec:proving}). Similarly to \texttt{||}, multiple \texttt{\&\&} can be used in sequence, and the operator \texttt{allOf} can be used for collections.

Using these operators, it is possible to produce more sophisticated scripts. For example, here is a script stating that the box can be spent either by Carol or by a collaboration between Alice and Bob:

\begin{verbatim}
        (pkA && pkB) || pkC
\end{verbatim}

A valid proof (contained in the spending transaction) will not reveal which of two possibilities was used.

Operators \texttt{allOf} and \texttt{anyOf} are actually special cases of the operator \texttt{atLeast(bound, collection)}, which requires the prover to know secrets for $\texttt{bound}$ elements of the \texttt{collection} (just in like in \texttt{anyOf}, which secrets the prover used will not be revealed by the proof). \texttt{allOf(collection)} is the same as \texttt{atLeast(collection.size, collection)} and $\texttt{anyOf(collection)}$ is the same as \texttt{atLeast(1, collection)}.

For example, here is a script stating that the box can be spent by any 3 out of the following 6 possibilities: Alice, Bob, Charlie, David and Edie, Frank and George, Helen and Irene:
\begin{verbatim}
        atLeast(3, Coll (pkA, pkB, pkC, pkD && pkE, pkF && pkG, pkH && pkI))
\end{verbatim}
The same result could be achieved by writing an \texttt{anyOf} of all possible 3-out-of-6 (twenty) combinations.

\subsection{Mixing $\Sigma$-statements with other statements}
\langname allows combining statements that require proofs with other boolean statements. These statements can refer to the \emph{context}, which has predefined variables with information about the transaction in which the script is evaluated (i.e., the box is spent). For example,

\begin{verbatim}
   pkA || pkB || (pkC && HEIGHT > 500)
\end{verbatim}
uses the predefined variable HEIGHT, which is the sequential block number (since the beginning of the blockchain, starting at 1)
of the block in which the script is evaluated.
This script allows Alice or Bob to spend the box before \texttt{HEIGHT} reaches 501, and Alice, Bob, or Carol to spend the box after that. If the height has not reached 501 and the box is spent, then the proof reveals that \texttt{skA} or \texttt{skB} was used in its construction, but does not reveal which one of the two. If \texttt{HEIGHT} is greater than 500, then the proof does not reveal which of the three secret keys was used. Thus, depending on the value of \texttt{HEIGHT}, the script becomes either equivalent to \texttt{pkA || pkB} or equivalent to \texttt{pkA || pkB || pkC}.

In general, script evaluation reduces the script to a $\Sigma$-statement by first evaluating all the Boolean predicates that are not $\Sigma$-statements. As we saw in the above example, the resulting $\Sigma$-statement will, in general, depend on the values of the Boolean predicates (such as whether \texttt{HEIGHT > 500}).

We emphasize that this evaluation is not the same as the usual left-to-right
lazy evaluation of logical expressions, because expressions involving
$\Sigma$-statements are not treated the same way as usual boolean
expressions: they are evaluated last and in zero-knowledge.

In fact, $\texttt{pkA}$ is not of type \texttt{Boolean}. It is a constant of
type \texttt{SigmaProp} with the concrete value
\texttt{ProveDlog(\texttt{ge})}, for some public key \texttt{ge} of
\texttt{GroupElement} type. The type \texttt{SigmaProp} is special in
\langname because it is used differently by the prover (who constructs the
proof) and the verifier (who checks it). In this case \texttt{ProveDlog}
require: 1) the prover (when the transaction is created) to provide a proof
of knowledge of the discrete logarithm corresponing to the value \texttt{ge};
2) the verifier (when the transaction is added to a block) to check that the
proof was indeed provided.

\subsection{Accessing the Context and Box Contents}
\label{sec:context}
In addition to the predefined variable \texttt{HEIGHT}, the context contains predefined collections \texttt{INPUTS} and \texttt{OUTPUTS}, which refer to the inputs and outputs of the spending transaction. Elements of these collections are of type \texttt{Box}. The script also has access to its own box via the context variable \texttt{SELF} of type \texttt{Box}. Note that \texttt{SELF} is also an element of the \texttt{INPUTS} collection, because the script is executed when the box is being spent.

To access information inside a box \texttt{b}, scripts can use \texttt{b.value} for the amount, \texttt{b.propositionBytes} for the protecting script, and \texttt{b.id} for the identifier of the box, which is the BLAKE2b-256 hash of the contents of the box. Boxes include additional information in \emph{registers};  each box is unique, because one of its registers includes the transaction id in which it was created as an output, and its own index in the outputs of the transaction which created the box, accessible through \texttt{b.R3} (see Section \ref{sec:box-registers} for more on registers).

\paragraph{Example: two boxes together}
Access to this information allows us, for example, to create an output box that can be spent only in the same transaction as another known box, and only if no other inputs are present in the transaction. If \texttt{friend} stands for an already existing box (per the environment mapping), then we create a new box that can be spent only together with \texttt{friend} and no other input by the following script (note that it uses the collection property \texttt{size} and collection indexing, starting at 0, denoted by parentheses):

\begin{verbatim}
        INPUTS.size == 2 && INPUTS(0).id == friend.id
\end{verbatim}

Note that the script does not prevent the \texttt{friend} box from being spent on its own, in which case the output box protected by the script above will become not spendable.

We can be more permissive and allow for other inputs in addition to the friend box. To do so, we will examine the input collection using the \texttt{exists} operator, which applies a boolean function to each collection element until it finds one that satisfies the function or finds that none exists. To define a function, we use lambda syntax; the argument type (in this case \texttt{Box}) is specified with a colon after the argument name \texttt{inputBox}. We name the function using the \texttt{def} keyword.
\begin{verbatim}
        {
                def isFriend(inputBox: Box) = inputBox.id == friend.id
                INPUTS.exists (isFriend)
        }
\end{verbatim}

This is our first example of a script with more than one statement; note that such scripts require braces, and their output is determined by the last statement.
It can also be written in one statement, as follows:
\begin{verbatim}
        INPUTS.exists { (inputBox: Box) => inputBox.id == friend.id }
\end{verbatim}

\paragraph{Example: crowdfunding}
Access to the context allows us to create a script for the following crowdfunding situation: a project backer (with key  \texttt{backerPubKey}) wishes to give money to a project (with key \texttt{projectPubKey}), but only if the project raises enough money (at least \texttt{minToRaise}) from other sources by a deadline (expressed in terms of \texttt{HEIGHT}).

To give money to the project, the backer will create an output box protected by the following script. The script contains two conditions: one for the case the deadline has passed (enabling the backer to get the money back) and one for the case it succeeded (enabling the project to spend the money if the amount is at least \texttt{minToRaise} before the deadline).  In order to ensure enough money has been raised, the script will search the output collection for a box with a sufficient value going to the \texttt{projectPubKey}. To check where the value of the output box is going, the script will read the script protecting the output box and compare it to the script \texttt{"projectPubKey"} (that is the simple script described in Section~\ref{sec:sigma-statements}); bytes of this script can be obtained by \texttt{projectPubKey.propBytes}.

\begin{verbatim}
        {
                val fundraisingFailure = HEIGHT >= deadline && backerPubKey
                val enoughRaised = {(outBox: Box) =>
                        outBox.value >= minToRaise &&
                        outBox.propositionBytes == projectPubKey.propBytes
                }
                val fundraisingSuccess = HEIGHT < deadline &&
                         projectPubKey &&
                         OUTPUTS.exists(enoughRaised)

                fundraisingFailure || fundraisingSuccess
        }
\end{verbatim}

As before, the values of \texttt{deadline}, \texttt{minToRaise}, and the two public keys are defined by the environment map and hardwired into the script at compile time.

\subsection{Context Extension and Hashing}
\label{sec:extension}
A context can also contain typed variables that can be retrieved by numerical id using the operator \texttt{getVar}. These variables are supplied by the prover specifically for a given input box (via a \texttt{ContextExtension}) together with the proof for that box. The id can be any one-byte value (from -128 to 127) and is scoped for each box separately (so variable with id 17 for one input box in a transaction is not the same as variable with id 17 for another input box in the same transaction).

Such context extensions can be useful, for example, for requiring a spending transaction to produce hash preimages (the BLAKE2b-256 and SHA-256 hash functions can be invoked in \langname, using keywords \texttt{blake2b256} and \texttt{sha256}). For example,
\begin{verbatim}
       pkA && blake2b256(getVar[Coll[Byte]](1).get) ==  hashOutput
\end{verbatim}
says that spending can be done only using the signature of Alice, and only if the preimage of \texttt{hashOutput} is written in the context. Specifically, the script requires that the context extension should contain a variable (with id \texttt{1}), which is a collection of bytes that hashes to the value of \texttt{hashOutput} (the value of \texttt{hashOutput}, like \texttt{pkA}, is defined in the environment and is hardwired into the script at compile time).  Note that although the script requires both the secret key corresponding to \texttt{pkA} and the hash preimage corresponding to \texttt{hashOutput}, there is the stark difference between how these two values are used: the secret key is not revealed in the proof (by the zero-knowledge property of $\Sigma$-proofs), while the hash preimage is explicitly written into the context extension and can be seen by anyone once the transaction takes place.

\paragraph{Example: atomic transactions and cross-chain trading}
Suppose there are two separate blockchains, for two different asset types. Alice wants to receive some assets in her blockchain in exchange for giving some assets to Bob in his blockchain. \langname allows to accomplish it in a simpler way than proposed for Bitcoin, for example, in \cite{Nol13}.

Alice creates a random secret \texttt{x} of 256 bits (32 bytes), hashes it to obtain the value \texttt{hx}, and creates a transaction in Bob's blockchain with the output box protected by the following script:
\begin{verbatim}
        anyOf( Coll(
                HEIGHT > deadlineBob && pkA,
                pkB && blake2b256(getVar[Coll[Byte]](1).get) == hx
        ))
\end{verbatim}
Bob can receive the value of this box only upon presentation of a hash preimage of \texttt{hx}. Alice can reclaim it after \texttt{deadlineBob}.

From this output, Bob learns \texttt{hx}. He creates a transaction in Alice's blockchain with an output box protected by the following script:
\begin{verbatim}
        val x = getVar[Coll[Byte]](1).get
        anyOf( Coll(
                HEIGHT > deadlineAlice && pkB,
                allOf( Coll(
                        pkA,
                        x.size < 33,
                        blake2b256(x) == hx
                ))
        ))
\end{verbatim}

If Alice is satisfied with the amount Bob is giving her, she claims the value of this box by revealing \texttt{x}. Alice is protected as long as the hash function is one-way and she keeps her \texttt{x} secret until she claims the value of this box. (She should be careful to submit her transaction in enough time before \texttt{deadlineAlice} to make sure it gets processed before Bob can reclaim this money, because once she submits the transaction, \texttt{x} is public and thus, if the \texttt{deadlineAlice} passes before the transaction is processed, Bob can both reclaim this box and claim the box Alice left in his blockchain.)

Bob is protected, because in order for Alice to claim the value of this box, she must present a hash preimage of \texttt{hx} as a context extension in the transaction that uses this box as input. But once she does, Bob also learns this hash preimage, and is able to claim the value of the box that Alice placed into his blockchain. Note that Bob needs to choose \texttt{deadlineAlice} early enough to make sure that he is able to learn the preimage of \texttt{hx} from the transaction in Alice's block chain, and create a transaction in his blockchain, all before \texttt{deadlineBob} that Alice chose. Note also that \texttt{HEIGHT} in the two scripts is with respect to two different blockchains, which may be growing at a different rate. Bob also needs to make sure that he can use Alice's \texttt{x} as a context extension; to make sure Alice cannot cheat by making this \texttt{x} so long that it will not be allowed as a context extension in his blockchain, he uses the constraint \texttt{x.size < 33}.

The same approach can be used to trade different assets on the same blockchain, in case of multi-assets blockchains. However, for transactions on a single blockchain, an alternative approach is also possible. We describe it below.

\subsection{Box Registers and Additional Tokens}
\label{sec:box-registers}
Together with its value and protecting script, a box can contain up to 10 numbered registers, \texttt{R0} through \texttt{R9}. The first four of these have fixed meaning, as follows. For a box \texttt{b}, \texttt{b.R0} is the same as \texttt{b.value} and \texttt{b.R1} is the same as \texttt{b.propositionBytes}.

The third register, \texttt{b.R2}, is for specifying additional, secondary tokens contained in the box (the primary token amount is specified in \texttt{b.value}). \texttt{b.R2} contains a collection of pairs, the first element of each pair specifying the token id (as a collection of 32 bytes) and the second element specifying the amount (as a long value). The maximum number of tokens in a box is set to 4. For every token id, the sum of amounts in inputs boxes must be no less than the sum of amounts in output boxes. There is one exception to this rule for the creation of new tokens. When a new token type gets created in a transaction, its id is equal to the id of the input box 0. Thus, the exception for the creation of new tokens is that if the token id in some output box is equal to the id of input box 0, then an arbitrary amount of this token can be output. Because each box has a unique id (see Section~\ref{sec:context}, this exception can be applied exactly once per token type. A newly created token can be emitted in a time-controlled fashion---see Section~\ref{sec:self-replicating}.

The fourth register, \texttt{b.R3}, contains a pair of integer and 34-byte collection~(its type then is $(Int, Coll[Byte])$). The collection specifies the 32-byte unique transaction id where this box appears as an output followed by a 2-byte sequence number of this box in the \texttt{OUTPUTS} collection of that transaction. This ensures that each box has unique \texttt{R3} and therefore a unique \texttt{id} as long as there are no hash collisions (because the \texttt{id} of the box is computed by hashing its content, including \texttt{R3}).
The first element of the pair contains creation height provided by user created the box. This height could only be less or equal than real inclusion height~
(a transaction could not be included into the blockchain if it contains an output with creation height being no greater than current blockchain height).

The remaining six registers can be used arbitrarily.

To access a register, the type of the register needs to be specified in brackets following the register number (for example, \texttt{b.R4[Int]}). Note that \texttt{b.R4[T]} is of type \texttt{Option[T]}; \texttt{b.R4[T].isDefined} indicates whether it actually contains a value of type \texttt{T}, and \texttt{b.R4[T].get} obtains this value.

In addition to registers, scripts can access two serialized versions of the box: \texttt{b.bytes} is a serialization of the entire box including all its registers, and \texttt{b.bytesWithNoRef}, which the same but without the transaction identifier and the output index~(so that a box can be viewed independently of where it appeared.

\paragraph{Example: atomic exchange on a single block chain}
These box registers provide additional capabilities to \langname. Consider, for example, Alice and Bob who want to exchange tokens: they agree that  Alice will give Bob 60 tokens of type \texttt{token1} (this type is mapped to an actual token id in the environment map) in exchange for 100 Ergo tokens. Alice could create an output box with value 100 and protect it with the following script:

\begin{verbatim}
  (HEIGHT > deadline && pkA) || {
    val tokenData = OUTPUTS(0).R2[Coll[(Coll[Byte], Long)]].get(0)
    allOf(Coll(
        tokenData._1 == token1,
        tokenData._2 >= 60L,
        OUTPUTS(0).propositionBytes == pkA.propBytes,
        OUTPUTS(0).R4[Coll[Byte]].get == SELF.id
    ))
  }
\end{verbatim}

This script ensures that the box can be spent only in a transaction that produces an output with 60 tokens of type \texttt{token1} and gives them to Alice (Alice can reclaim the box after the deadline).
Moreover, the last condition (\texttt{OUTPUTS(0).R4[Col[Byte]].get == SELF.id}) ensures that if Alice has multiple such boxes outstanding at a given time, each will produce a separate output that identifies the corresponding input. This condition prevents the following attack: if Alice has two such boxes outstanding but the last condition is not present, then they can be both used in a single transaction that contains just one output with 60 tokens of type \texttt{token1} --- the script of each input box will be individually satisfied, but Alice will get less only half of what owed to her.

Bob, similarly, could create an output box with value about 0 and 60 tokens of type \texttt{token1} and protect it by the following script:
\begin{verbatim}
        (HEIGHT > deadline && pkB) ||
        allOf( Coll(
                OUTPUTS(1).value >= 100L,
                OUTPUTS(1).propositionBytes == pkB.propBytes,
                OUTPUTS(1).R4[Coll[Byte]].get == SELF.id,
         ))
\end{verbatim}

A transaction containing these two boxes as inputs must produce two outputs: the first giving at least 60 tokens of type1 to Alice and the second giving at least 100 tokens of type2 to Bob. Once the two boxes are on the blockchain, anyone can create such a transaction using the two boxes as inputs, and thus effect the exchange between Alice and Bob. Unlike the cross-chain trading example above using hashing (which requires one side to go first), there are no potential problems with synchronization here, because the exchange will happen in a single transaction or will not happen at all.
\subsection{Self-Replicating Code}
\label{sec:self-replicating}
Access to box registers allow us to create self-replicating boxes, because a script can check that an output box contains the same script as \texttt{SELF}. As shown in \cite{CKM18}, this powerful tool allows for Turing-completeness as computation evolves from box to box, even if each individual script is not Turing-complete. We will demonstrate two examples of complex behavior via self-replication.

\paragraph{Example: time-controlled coin emission}
In this example, we will create a self-replicating box that emits new coins at each time step in order to add to the total amount of currency available. This box appears as an output in the genesis block (at height 0) of the blockchain; all "new" coins come from this box or its descendants, thus maintaining the invariant that for every transaction after the genesis block, the combined value of all inputs  is equal to the combined value of all outputs.

The value of this box initially is equal to the total amount of currency that will eventually be available. This value will go down by a prespecified amount each time this box is transacted. Because in each transaction, the sum of input values must equal the sum of output values, when the value of this box goes down, the difference must be claimed by someone. The box is set up to allow the difference to go to anyone---presumably, it will be claimed by the miner who created the block that contains the transaction. This box will store, in \texttt{R4}, the height at which it was created. Using this information, it will be able to determine how much value to emit. The box will be set to emit
a fixed amount specified by \texttt{fixedRate} per block until \texttt{HEIGHT} reaches \texttt{fixedRatePeriod}, and a linearly decreasing amount thereafter. The script will verify that the output box has the same script as itself, and that the new height stored in \texttt{R4} and the new value are correctly computed (and that the height has increased, so that a miner cannot emit more than once per block). The following script accomplishes this goal:
\begin{verbatim}
      {
              val epoch = 1 + ((HEIGHT - fixedRatePeriod) / epochLength)
              val out = OUTPUTS(0)
              val coinsToIssue = if(HEIGHT < fixedRatePeriod) fixedRate
                                 else fixedRate - (oneEpochReduction * epoch)
              val correctCoinsConsumed = coinsToIssue == (SELF.value - out.value)
              val sameScriptRule = SELF.propositionBytes == out.propositionBytes
              val heightIncreased = HEIGHT > SELF.R4[Int].get
              val heightCorrect = out.R4[Int].get == HEIGHT
              val lastCoins = SELF.value <= oneEpochReduction
              allOf(Coll(
                      heightCorrect,
                      heightIncreased,
                      sameScriptRule,
                      correctCoinsConsumed))
              || (heightIncreased && lastCoins)
      }
\end{verbatim}

\paragraph{Example: arbitrary computation via a simple cellular automaton}
The example in the paragraph is not meant for practical implementation; rather, it is here merely to demonstrate the Turing-complete power of self-replication. It implements the so-called ``rule 110'' one-dimensional cellular automaton \cite{wolfram1986theory}, which is known to be Turing-complete \cite{cook2004universality} (with only polynomial-time overheard --- i.e., $P$-complete \cite{NW06}). See \cite{CKM18}  for more details. The code for this example is too complex to be put here; it is available at
\url{https://github.com/ScorexFoundation/sigmastate-interpreter/blob/master/src/test/scala/sigmastate/utxo/examples/Rule110Specification.scala}.

\ignore{
\subsection{Merkle Trees}
Explain \texttt{isMember} and provide an example of usage. Explain that the context also contains the root hash of the all the unspent output boxes in the previous block \lnote{check: previous or current block? It would seem that the current is not available, so it should be previous.}, available via the predefined variable \texttt{LastBlockUtxoRootHash}. Give examples of usage, such as oracle, MAST, FSM. (For the oracle, explain that our language is rich enough to support signature verification within the script.)
}

\section{Implementation}
\label{sec:impl}
A script is converted to an abstract syntax tree using standard compilation techniques. At evaluation time, values from the context are substituted for relevant variables and the tree is evaluated. There are two significant differences from standard compilation and evaluation techniques:

\begin{itemize}
\item We estimate the time required to process the script and, if it exceeds a certain bound, refuses to evaluate it in order to prevent a denial-of-service attack.
\item The evaluation converts the script not to a Boolean value, but to a $\Sigma$-statement. This statement is a tree, with  \texttt{proveDlog} or \texttt{proveDHtuple} nodes for leaves, and $\andnode$ (\texttt{\&\&}), $\ornode$ (\texttt{||}), or $\tnode$ for  non-leaves. The prover (when trying to use in a transaction the box that is protected by the script) generates a proof this $\Sigma$-statement. The verifier verifies it, obtaining a Boolean value.
\end{itemize}

We describe the latter non-standard step in Appendix \ref{app:crypto}, while the former will be described in a separate
upcoming document.

\section{Further Work}
\label{sec:further}

The next steps we plan to do~(and have partially done) after releasing this document are:
    \begin{enumerate}
        \item{} More examples, including non-interactive and fully on-chain tumbler for mixing the coins, cold wallets,
        oracles, initial coin offering scenario, multi-state contract defined as a finite state machine, and so on. We
        already have code for such the examples done, and writing documentation about them at the moment.
        \item{} Detailed description of used type system, cost estimation procedure, safety guarantees,
        and abstract syntax tree format.
    \end{enumerate}
\bibliographystyle{alpha}
\bibliography{sigma.bib}

\appendix

\ignore {

\section{Safety Guarantees}
\label{app:safety}

We need to be sure that an adversary can not produce such a statement for
which the Verifier spends more time than it is safe to spend.

In order to filter out malicious statements, Verifier needs to perform a
series of safety checks, in particular, consistency checks and execution cost
estimations. These safety checks also require Verifier to spend some
time. However, the idea is to strictly limit overall complexity of the checks to be
linear in the size of the statement tree and input data, which are strictly
limited in size.

Verification and safety checks are performed in following stages.

\subsection{Verification and Safety Checks}
\label{sec:safety-checks}

Verifier performs the following safety checks:

\begin{enumerate}
\item \textbf{Deserialization of Statement.}
Verifier receives the statement as a collection of bytes and checks that the
size of collection is less than predefined constant $C_1$. Deserializer parses
the collection of bytes and checks if it is according to the format.
Deserializer also controls the size of the constructed statement tree. It should
be less than predefined constant $C_2$. The tree being constricted is also
checked to satisfy typing rules. After deserialization stage we have valid tree
of known limited size $TreeSize$ and depth $TreeDepth$. We want the complexity
of all subsequent checks to be $O(TreeSize)$.

\item \textbf{Instantiation of the Cost Function.}
Cost Function is the function of the same input (Context, variables,
registers, etc.) as Statement function, but it computes Int value of the
computation cost of the Statement function, so it answer the question "How
many operations it is required to compute the statement?".

The Cost Function is instantiated by the following steps:
    \begin{enumerate}
        \item{}
    \end{enumerate}

 The idea is that the complexity of obtaining the Cost Function ($genCF$) is
 linear in the size of the Statement tree. Execution time of the Cost Function
 is linear in the size of the input data of the Statement which is strictly
 limited in size.

\item \textbf{Evaluating the Statement cost.}
The Cost Function is applied right before evaluation of the Statement by the
following steps:
    \begin{enumerate}
        \item construct the context as it is required for Statement evaluation
        \item invoke the interpreter to evaluate the Cost Function in the
        given context
        \item check resulting cost limit
    \end{enumerate}

The generation of the CFT is further described in
section~\ref{sec:gen-cost-function}. Upon computing the cost of Statement
using Cost Function the Verifier check that it is less than the predefined
constant $C_3$.
\end{enumerate}

Passing all three stages of safety checks above, the Verifier is safe to
evaluate the Statement tree in a current data context. This Statement
evaluation is guaranteed to terminate in the estimated amount of time.

\subsection{Generation of Cost Function Tree}
\label{sec:gen-cost-function}

Here we briefly describe an algorithm $genCF$ to construct a Cost Function
tree. The basic idea is that we perform single traversal of the Statement
tree, visiting all the nodes from leaves up to the root. During traversal
foreach Statement node $t$ with children ${c_1 \dots c_k}$ we
construct$genCF(t)$ using ${genCF(c_1) \dots genCF(c_n)}$. Algorithm $genCF$
is defined recursively over the tree structure as shown in
Figure~\ref{fig:genCFT}. In the figure $dataCost(v)$ is a function to compute
a cost of the evaluated value $v$ represented either by $ContextVar$ of
$Constant$ tree nodes.

\begin{figure}
\begin{center}
\begin{tabular}{>{$}l<{$} >{$}c<{$} >{$}l<{$}}
    \multicolumn{3}{@{}l}{\textbf{def} $genCF(D: Context, t: Value[T]): Value[Long]$}  \\
    D, v~@~ContextVar(\_) & \to & dataCost(v) \\
    D, c~@~Constant(\_) & \to & dataCost(c) \\
    D, t_1 \otimes t_2 & \to & genCF(D, t_1) + Cost_\otimes + genCF(D, t_2) \\
    arr.map(f) & \to &
        \begin{tabular}[t]{l}
            val $f_{cost}$ = $genCF(D, f)$ \\
            $sum(arr.map(\lambda x \to f_{cost}(x)))$ \\
        \end{tabular} \\
     & \to & $\mnote{arg}$ \\
    % v @ Constant(_) & \to &
    %     \begin{tabular}[t]{l}
    %         $v :=$ variable with $varId$ from data environment \\
    %         return $dataCost(v)$ \\
    %     \end{tabular} \\
\end{tabular}
\caption{Algorithm $genCFT$}
\label{fig:genCFT}
\end{center}
\end{figure}

}

\section{Implementation of Noninteractive $\Sigma$-protocols for an arbitrary And/Or/Threshold composition}
\label{app:crypto}
\subsection{Background}

In this section, we explain in detail how the $\Sigma$-protocol proving and verifying is implemented. Consider the tree after the evaluation process, as described in Section~\ref{sec:impl}, reduces it to only $\Sigma$-protocol nodes. Then the leaves of the tree are atomic $\Sigma$-protocols, and non-leaves are of one of three types: $\andnode$ (corresponding to \texttt{\&\&} or \texttt{allOf} in \langname), $\ornode$ (corresponding to \texttt{||} or \texttt{anyOf} in \langname), or $\tnode(k)$ (corresponding to \texttt{atLeast} in \langname).

The meaning of the proof corresponding to $\tnode(k)$ is ``the prover knows witnesses for at least $k$ children of this node''. Semantically, $\andnode$ and $\ornode$ are simply special cases of $\tnode$: the meaning  of the proof corresponding $\andnode$ (respectively, $\ornode)$ is ``the prover knows witnesses for all children (respectively, at least one child) of this node''. However, $\andnode$ and $\ornode$ are implemented differently from $\tnode$ for efficiency.

For the purposes of this description, it does not matter what specific atomic $\Sigma$-protocols are used at the leaves. They can be, for example, \texttt{proveDlog(x)} for proving knowledge of the discrete logarithm $w$ of $x=g^w$, or \texttt{proveDHtuple(g1, g2, u1, u2)} for proving that $(g_1, g_2, u_1, u_2)$ form a Diffie-Hellman tuple, i.e., $\exists w \mbox{\ such\  that\ } u_1 = g_1^w \, \wedge \, u_2 = g_2^w$. In general, we will assume the prover has some secret $w$ and wants to prove some property of it.

A $\Sigma$-protocol consist of three messages:

\begin{itemize}
\item a \emph{commitment} $a$ sent from the Prover to the Verifier (computed using the witness $w$ and some freshly generated secret randomness $r$ by the Prover's first step algorithm);
\item a uniformly random \emph{challenge} $e$ sent from the Verifier to the Prover;
\item and a \emph{response} $z$ sent from the Prover to the Verifier (computed using the randomness $r$, the challenge $e$, and the witness $w$ by the Prover's second step algorithm).
\end{itemize}
The verifier then checks that the triple $(a, e, z)$ satisfies some formula and, if so, accepts the proof.

In order to make an atomic $\Sigma$-protocol non-interactive using the so-called Fiat-Shamir heuristic, the Prover would compute $e$ by hashing $a$, and the Verifier would check that $e$ is indeed a hash of $a$. However, once atomic $\Sigma$-protocols are composed using $\andnode$, $\ornode$, and $\tnode$, the challenge computation becomes more involved, as we describe below.

$\Sigma$-protocols have the property of \emph{special honest-verifier zero-knowledge}. For the purposes of this description, it means that given a random $e$, it is possible to compute $a$ and $z$ without knowing the secret witness $w$ that is normally needed by the prover. This computation is called ``simulation''. Moreover, the triple $(a, e, z)$  computed via simulation is distributed identically to the triple $(a, e, z)$ that results form a $\Sigma$-protocol that is run by the honest prover (who knows the secret witness $w$) and verifier (who generates a uniform $e$). The trick that makes simulation possible is that the response $z$ is chosen by the simulator before commitment $a$, in contrast to the prover, who is forced to choose $a$ before $z$.

$\Sigma$-protocols used in this work must also satisfy a property of \emph{special soundness}, which means that given two triples $(a_1, e_1, z_1)$ and $(a_2, e_2, z_2)$ that are both accepted by the verifier, and $a_1=a_2$ while $e_1\neq e_2$, it is possible to compute the Prover's secret witness $w$ in polynomial time and thus directly verify that the statement claimed by the Prover is true.   Note that this computation is never performed, because the Prover will never actually answer two different challenges $e_1\neq e_2$ for the same commitment $a_1=a_2$.

In order for composition of $\Sigma$-protocols using $\andnode$, $\ornode$, and $\tnode$ to work, the challenge $e$ in all protocols must be a binary string of the same length, which we will call $t$.  (This implies that if the Verifier performs arithmetic modulo $q$ on $e$, then $2^t<q$; else it would be trivial to have $e_1\neq e_2$ by letting $e_2=e_1+q$, and the same $z$ would work for both $e_1$ and $e_2$, violating the special soundness property mentioned above, because such $a, e_1, z$ can be computed without knowledge of the witness $w$ by using the simulator.)  Note that $t$ is the \emph{soundness parameter}: the probability that a malicious Prover can fool the Verifier in a single attempt is $2^{-t}$.

 For ease of description, we will also impose the following limitation on the $\Sigma$-protocols: in the interactive version, the verification code must proceed by computing $a'$ from $z$ and $e$, and then checking if $a'=a$. That means that in the noninteractive version, the Prover needs to transmit only $z$ and $e$ (omitting $a$) to the Verifier, who will compute $a'$ from $z$ and $e$ and then check that $e$ was computed correctly as a function of $a'$. If the hashing is second-preimage-resistant, an incorrect $a'$ will lead to a mismatch of $e$, which will be detected by the Verifier. This limitation is satisfied by most common $\Sigma$-protocols; it is not essential and can be removed by having the Prover additionally send $a$.

We show the steps of the prover and verifier given such a tree. While $\andnode$, $\ornode$, and $\tnode$ composition of $\Sigma$-protocols has been addressed in the literature before \cite{CDS94}, prover and verifier algorithms have been described only for a single node, in terms of prover, verifier, and simulator algorithms for its children. Recursively constructing code for an entire tree by dynamically constructing prover, verifier, and simulator code for each node is inefficient. Here we take a different approach by explicitly describing how and in what order the protocol messages for each node of the tree need to be computed and verified. We are not aware of any similar descriptions in the literature.

Our description uses two kinds of tree traversal: bottom-up (also known as post-order) and top-down (also known as preorder). In a bottom-up traversal, for each node, operations are recursively applied to the children of the node before being applied to the node itself. In a top-down traversal, for each node, operations are applied to the node itself before being recursively applied to each of its children.

\subsection{Proving}
\label{sec:proving}

The Prover will know secret witnesses $w$ for some of the leaves; for such leaves, it will choose whether to produce real or simulated proofs according to the algorithm described in this section. The Prover will simulate proofs for all other leaves.

\paragraph{Multiple provers} There may be situations when the secret witnesses $w$ at the leaves are distributed among several different provers, who will have to cooperate but will not have to reveal the secrets to each other; in this case, we assume there is a main prover carrying out the steps below, and we explain what the other provers need to do in order for the main prover to construct the proof. We caution that the proofs will not be zero-knowledge to the other provers nor to an adversary who can observe the communication between the provers---even just the existence of communication will reveal which parts of the tree are real and which are simulated. Moreover, if the main prover is malicious, it may be able to attack the other provers --- see Step \ref{step:response} below. More sophisticated multi-party computation protocols to address this problem are available, but are outside of the scope of this paper.

\paragraph{Side-channel attacks}
Note that the algorithm described below does not attempt to be secure against side channel attacks, such as, for example, timing attacks. In particular, it may take different amounts of time depending on which nodes are real and which are simulated; a timing attacker may therefore obtain information about the set of leaves for which the Prover knows the secrets. If timing attacks are a concern, it is not enough to make sure that simulation and proving take a similar amount of time for each atomic $\Sigma$-protocol used in the leaves; implementations should also make sure that tree traversals take the same amount of time regardless of where simulated and real $\Sigma$ protocols are located in the tree. In particular, implementations should avoid the use of lazy-evaluation constructs, such as ``forall'' and ``exists''.

\paragraph{The steps}
For each node in the tree, the prover will maintain a flag indicating whether it is real or simulated. Each node will also have a $t$-bit challenge. The leaves will additionally have two protocol values: a challenge and a response. The pseudocode below explains how these values are computed. In the pseudocode below, the word ``random'' should be read to also allow securely generated pseudorandom values.

The prover first has to decide which nodes will have real proofs (for which witnesses are required) and which will be simulated. For example, in an $\ornode$ proof, only one of the children will be real. The prover will do so based on witnesses that are available, in three steps:

\begin{enumerate}
    \item \label{step:initial-simulated} This step will mark as ``real'' every node for which the prover can produce a real proof. This step may mark as ``real'' more nodes than necessary if the prover has more than the minimal necessary number of witnesses (for example, more than one child of an $\ornode$).  This will be corrected in the next step. In a bottom-up traversal of the tree, do the following for each node:
        \begin{itemize}
            \item If the node is a leaf, mark it ``real'' if the witness for it is available; else mark it ``simulated''
            \item If the node is $\ornode$, mark it ``real'' if at least one child is marked real; else mark it ``simulated''
            \item If the node is $\andnode$, mark it ``real'' if all of its children are marked real; else mark it ``simulated''
            \item If the node is $\tnode(k)$, mark it ``real'' if at least $k$ of its children are marked real; else mark it ``simulated''
        \end{itemize}

    \item If the root of the tree is marked ``simulated'' then the prover does not have enough witnesses to perform the proof. Abort.

    \item This step will change some ``real'' nodes to ``simulated'' to make sure each node has the right number of simulated children.
          In a top-down traversal of the tree, do the following for each node:
        \begin{itemize}
            \item
            If the node is $\ornode$ marked ``real'',  mark all but one of its children ``simulated''
            (the node is guaranteed by step~\ref{step:initial-simulated} to have at least one ``real'' child).
            Which particular child is left ``real'' is not important for security; the choice can be guided by efficiency or convenience considerations.
            \item
            If  the node is $\tnode(k)$ marked ``real'', mark all but $k$ of its children ``simulated''
            (the node is guaranteed, by the previous step, to have at least $k$ ``real'' children).
            Which particular ones are left ``real'' is not important for security; the choice can be guided by efficiency or convenience considerations.
            \item
            If the node is marked ``simulated'', mark all of its children ``simulated''
        \end{itemize}
\end{enumerate}

\noindent
Now the prover will compute protocol values for every node, as follows:

\begin{enumerate}
\setcounter{enumi}{3}
    \item In a top-down traversal of the tree, compute the challenges $e$ for simulated children of every node, as follows:
    \begin{itemize}
        \item If the node is marked ``real'', then each of its simulated children gets  a fresh uniformly random challenge in $\{0,1\}^t$. (Note that a real $\andnode$ node has no simulated children, so this step applies only to real $\ornode$ and $\tnode$ nodes.)
        \item If the node is marked ``simulated'', let $e_0$ be the challenge computed for it.  All of its children are simulated, and thus we compute challenges for all of them, as follows:
        \begin{itemize}
            \item If the node is $\andnode$,  then all of its children get $e_0$ as the challenge
            \item If the node is $\ornode$, then each of its children except one gets a fresh uniformly random challenge in $\{0,1\}^t$. The remaining child gets a challenge computed as an XOR of the challenges of all the other children and $e_0$.
            \item If the node is $\tnode(k)$, assume it has $n$ children numbered from $1$ to $n$. There are two possible algorithms. The first algorithm is faster than the second. However, it is also faster than the algorithm for a ``real'' $\tnode$ node; therefore, if a timing attack on the prover is a possibility, then it should not be used, because the timing attack may be able to distinguish a ``real'' $\tnode$ node from a ``simulated'' one.
            \begin{enumerate}
            	\item The faster algorithm is as follows. Pick  $n-k$ fresh uniformly random values $q_1, \dots, q_{n-k}$ from $\{0,1\}^t$ and let
	         $q_0=e_0$. Viewing $1, 2, \dots, n$ and $q_0, \dots, q_{n-k}$ as elements of $\GF(2^t)$,
	         evaluate the polynomial $Q(x) = \sum {q_i x^i}$ over $\GF(2^t)$ at points $1, 2, \dots, n$
	         to get challenges for child $1, 2, \dots, n$, respectively.
	         \item The algorithm with better resistance to timing attacks is as follows. Pick $n-k$ fresh uniformly random values $e_1, \dots, e_{n-k}$
	         as challenges for the children number $1, \dots, n-k$.
	         Let $i_0 = 0$. Viewing $0, 1, 2, \dots, n$ and $e_0, \dots, e_{n-k}$ as elements of $\GF(2^t)$, find (via polynomial interpolation) the
	          lowest-degree polynomial $Q(x)=\sum_{i=0}^{n-k} a_i x^i $ over $\GF(2^t)$ that is equal to $e_j$ at $j$ for each $j$ from
	          $0$ to $n-k$ (this polynomial will have $n-k+1$ coefficients, and the lowest coefficient will be $e_0$). Set the challenge at child
	          $j$ for $n-k<j\le n$ to equal $Q(j)$.
 	   \end{enumerate}
        \end{itemize}
    \end{itemize}

    \item For every leaf marked ``simulated'', use the simulator of the $\Sigma$-protocol for that leaf to compute the commitment $a$ and the response $z$, given the challenge $e$ that is already stored in the leaf.

    \item \label{step:realcom} For every leaf marked ``real'', use the first prover step of the $\Sigma$-protocol for that leaf to compute the necessary randomness $r$ and the commitment $a$. In case of multiple provers responsible for different leaves, each prover individually computes the randomness $r$ for that leaf; the provers send their commitments $a$ to the main prover (note that the existence of this communication, if observed the adversary, will reveal to the adversary which leaves are real).

    \item \label{step:fs}  Convert the tree to a string $s$ for input to the Fiat-Shamir hash function. The conversion should be such that the tree can be unambiguously parsed and restored given the string. For each non-leaf node, the string should contain its type ($\andnode$, $\ornode$, or $\tnode(k)$). For each leaf node, the string should contain the $\Sigma$-protocol statement being proven and the commitment. The string should not contain information on whether a node is marked ``real'' or ``simulated'', and should not contain challenges, responses, or the real/simulated flag for any node.

    \item Compute the challenge for the root of the tree as the Fiat-Shamir hash of $s$ (and, if applicable,  the associated data, such as the message being signed).

    \item \label{step:response} Perform a top-down traversal of only the portion of the tree marked ``real'' in order to compute the challenge $e$ for every node marked ``real'' below the root and, additionally, the response $z$ for every leaf marked ``real'' (note that nodes marked ``simulated'' have all their descendants marked ``simulated'' and all the challenges for these descendants already computed, so there is no need to recurse down ``simulated'' nodes, unless timing attacks are a concern). For every node, do the following:

    \begin{itemize}
        \item If the node is a non-leaf marked ``real'' whose challenge is $e_0$, proceed as follows:

        \begin{itemize}
            \item If the node is $\andnode$, let each of its children have the challenge $e_0$
            \item If the node is $\ornode$, it has only one child marked ``real''. Let this child have the challenge equal to the XOR of the challenges of all the other children and $e_0$
            \item If the node is $\tnode(k)$, number its children from $1$ to $n$. Let $i_1, \dots, i_{n-k}$ be the indices of the children marked ``simulated'' and $e_1, \dots,  e_{n-k}$ be their corresponding challenges. Let $i_0 = 0$. Viewing $0, 1, 2, \dots, n$ and $e_0, \dots, e_{n-k}$ as elements of $\GF(2^t)$, find (via polynomial interpolation) the lowest-degree polynomial $Q(x)=\sum_{i=0}^{n-k} a_i x^i $ over $\GF(2^t)$ that is equal to $e_j$ at $i_j$ for each $j$ from $0$ to $n-k$ (this polynomial will have $n-k+1$ coefficients, and the lowest coefficient will be $e_0$). For child number $i$ of the node, if the child is marked ``real'', compute its challenge as $Q(i)$ (if the child is marked ``simulated", its challenge is already $Q(i)$, by construction of $Q$).
        \end{itemize}

        \item If the node is a leaf marked ``real'', compute its response $z$ according to the second prover step of the $\Sigma$-protocol given the randomness $r$ used for the commitment $a$, the challenge $e$, and witness $w$. In case of multiple provers, the main prover will send the relevant challenges to other provers, who will respond with the relevant $z$. It is crucial for security that the provers do not respond to more than one challenge $e$ for a given commitment $a$. Again, like in Step \ref{step:realcom}, the mere existence of this communication reveals which leaves are real and which are simulated. Moreover, if the main prover chooses the challenge $e$ maliciously for another prover, the zero-knowledge property of the other prover's secret is not preserved (although, for most $\Sigma$-protocols, no useful information about the other prover's secret will be revealed for any, even maliciously chosen, $e$; but a malicious choice of $e$ may make side-channel attacks easier).

    \end{itemize}

    \item Output the proof consisting of the following information:
    \begin{itemize}
        \item The challenge of the root node
        \item For every $\ornode$ node: the challenges of all of its children but the rightmost
        \item For every $\tnode$ node: the coefficients $q_1 \dots q_{n-k}$ of the polynomial $Q(x)$ (excluding $a_0$)
        \item The responses for every leaf node
    \end{itemize}
\end{enumerate}

\subsection{Verifying}
\label{sec:verifying}

For each node in the tree, the verifier will obtain a $t$-bit challenge $e$ by either reading it directly from the proof or by using other information provided in the proof. For the leaves, the verifier will also read the response $z$ from the proof and will re-compute, using the challenge and the response, the commitment $a$.  Finally, verifier will hash the whole tree and will check that the hash value matches the challenge of the root node.

Note that, unlike the prover, the verifier has no way of knowing which nodes are real and which are simulated. In fact, making sure that the verifier cannot tell the difference between real and simulated nodes is one of the security goals of the protocol.

The pseudocode below details the verifier's steps.

\begin{enumerate}
\item Read the root challenge from in the proof.

\item In a top-down traversal of the tree, obtain the challenges for the children of every non-leaf node by reading them from the proof or computing them, as follows. Let $e_0$ be the challenge in the node.
        \begin{itemize}
            \item If the node is $\andnode$,  then all of its children get $e_0$ as the challenge
            \item If the node is $\ornode$, then each of its children except rightmost reads its challenge from the proof. The rightmost child gets a challenge computed as an XOR of the challenges of all the other children and $e_0$.
            \item If the node is $\tnode(k)$, let the number of its children be $n$. Assume the children are numbered from $1$ to $n$. Let $q_0=e_0$ and read the values $q_1, \dots, q_{n-k}$ from the proof. Viewing $1, 2, \dots, n$ and $q_0, \dots, q_{n-k}$ as elements of $\GF(2^t)$, evaluate the polynomial $Q(x) = \sum {q_i x^i}$ over $\GF(2^t)$ at points $1, 2, \dots, n$ to get challenges for child $1, 2, \dots, n$, respectively.
        \end{itemize}

 \item For every leaf node, read the response $z$ provided in the proof.

\item For every leaf node, compute the commitment $a$ from the challenge $e$ and response $z$, per the verifier algorithm of the leaf's $\Sigma$-protocol. If the verifier algorithm of the $\Sigma$-protocol for any of the leaves rejects, then reject the entire proof.

\item Convert the tree to a string $s$ for input to the Fiat-Shamir hash function, using the same conversion as the prover in Step~\ref{step:fs}

\item Accept the proof if the challenge at the root of the tree is equal to the Fiat-Shamir hash of $s$ (and, if applicable,  the associated data). Reject otherwise.
\end{enumerate}

\ignore {

\section{Types}
\label{sec:types}

All the operations as well as operands have types. For example, addition operation ``+'' may take two Int and returns an Int value. Comparison operation ``$>$'' takes two Int and returns a boolean value. Some operations may be overloaded so that the same symbol is reused for operations acting on different types, e.g. $+: (Int,Int) \to Int$, $+: (Long, Long) \to Long$ etc.
We consider statements provable via $\Sigma$-protocols, like $dlog(x)$ as instances of the boolean type. The interpreter checks that all the nodes in the tree have children of appropriate types, and the whole guarding expression~(the root node of the tree) has a boolean type and rejects the expression if the conditions are not met.

We have following types in the language:

\begin{itemize}
    \item{signed integer types of 8, 16, 32 and 64-bits size}
    \item{big integer type of arbitrary size}
    \item{boolean}
    \item{avl+ tree verification data}
    \item{cryptography group element}
    \item{box}
    \item{tuple of values of different types}
    \item{collection of values of the same type}
    \item{optional value}
\end{itemize}

\subsection{Rewriting a Tree}
\label{sec:rewriting}

By parsing a statement, interpreter first builds a tree from a formula. For the example~\ref{eq:example1} the tree would be as following:

\knote{draw the tree}.

If the tree is well-formed according to the typing rules, and also has complexity no more than an allowed limit, interpreter is going to rewrite it, in potentially many steps. For every step, the interpreter tries, going from bottom to top of the tree, to replace nodes which are ready to be transformed~(operands are in place, and the transformation itself is known). The next step is about the same transformations in the same bottom-top order to be done. The process finishes in one of the following cases:

\begin{itemize}
    \item{abort: } happens if transformation process by its complexity exceeds an upper bound. The complexity estimation works as follows. The interpreter remembers initial cumulative complexity $C_0$, and for each replacement in the tree it calculates cumulative complexity of a subtree to be inserted instead of a subtree to be removed $\Delta C$, and adds $\Delta C$ to current cumulative complexity $C$, where $C = C_0$ initially.
    \item{success: } we finish with this status if during last step there are no any transformations done.
\end{itemize}

If the transformations are finishing with abortion, the result is considered as $false$ (we recall that the interpreter is giving a single boolean result finally, whether an output could be spent or not). Otherwise, if the tree could not be transformed anymore the interpreter is looking into it. If the tree is about just a single node which contains boolean constant value~($true$ or $false$), the value is the result of the interpretation. If the tree contains statements not provable via $\Sigma$-protocols, the interpreter finishes with $false$. Otherwise, if the tree contains only statements provable via $\Sigma$-protocols, the interpreter is continuing to work, and here execution is different for the prover and the verifier. The prover is generating a proof for the statement by using its secrets, as described in Section~\ref{sec:proving}, and the verifier checks the statement against the proof~(provided in a spending transaction), as described in Section~\ref{sec:verifying}. The verifier outputs $true$ if the proof is valid for the statement, $false$ otherwise. We are skipping for now the question how Fiat-Shamir transformation works in our setting, and how a message, which is used in a non-interactive protocol is formed; details are given further in Appendix~\ref{apx:tx-format}.

\section{Oracle Example}

\knote{Text below is just copied from code comments, polish it}

A trusted weather station is publishing temperature data on blockchain. Alice and Bob are making a contract based on the data:
they have locked coins in such way that if output from the station shows that temperature announced by the oracle is > 15 degrees, money are going to Alice, otherwise to Bob.

We consider that for validating transaction only limited number of last headers and the spending transaction should be enough, in addition to outputs being spent by the transaction. Thus there is no need for knowledge of an arbitrary output. To show the coin of the weather service in the spending transaction, outputs from Alice and Bob are referencing to the coin by using Merkle proofs against UTXO set root hash of the latest known block.

A tricky moment is how Alice and Bob can be sure that a coin is indeed created by the service, having just the coin (and also service's public key x = $g^w$, where service's secret w is not known.

For that, we consider that the service creates a coin with registers of following semantics (R0 and R1 are standard):

R1 - coin amount
R2 - protecting script, which is the pubkey of the service, $x = g^w$
R3 - temperature data, number
R4 - $a = g^r$, where r is secret random nonce
R5 - $z = r + ew mod q$
R6 - timestamp

Then Alice and Bob are requiring from the coin that the following equation holds: $g^z = a * x^e$, where $e = hash(R3 ++ R6)$

Thus Alice, for example, is created a coin with the following statement (we skip timeouts for simplicity):
"the coin is spendable by presenting a proof of Alice's private key knowledge if against UTXO set root hash for
the last known block there is a coin along with a Merkle proof, for which following requirements hold:
$R2 = dlog(x) /\ g^(R5) = R4 * x^(hash(R3 ++ R6)) /\ (R3) > 15$. Similarly, the coin is spendable by a proof of
knowledge of the Bob's private key if all the same conditions are met but $(R3) <= 15$.".

The Bob can create a box with the same guarding conditions. However, if Alice's box is already in the state, then Bob can stick to it by using the trick from the "along with a brother" test.

\section{Open Questions}

\begin{enumerate}
  \item Q: Let's use $\lor$, $\land$ for logical connectives, and $\sqcup$, $\sqcap$ for
           sigma-connectives correspondingly? \linebreak
        A:
  \item Q: Do we have "knowledge of Pedersen commitment $x_2$ preimage" somehow implemented? \linebreak
        A:
  \item Q: What are the limitations of \langname? \linebreak
        A: The following are the constraint of current implementation of \langname:
        \begin{itemize}
          \item Let bound expressions are copied in every usage site during compilation. This leads to repeated evaluation of the corresponding expressions.
          \item Lambdas are not first-class. After compilation all Lamdas should be inlined.
          \item Nested collections are not supported
        \end{itemize}
\end{enumerate}

\section{Types}

\[\begin{tabular}{@{}l c l l}
      $\mathcal{T} \ni \tau$			& ::= 	    &\
         \lst{Byte} $\mid$ \lst{Short} $\mid$
         \lst{Int} $\mid$ \lst{Long} $\mid$ \lst{BigInt}  & numeric types     \\
      &	$\mid$	& \lst{Boolean} 			& type of logical values true/false   \\
      &	$\mid$	& \lst{Unit} 				& type with single element   \\
      &	$\mid$	& \lst{GroupElement} 		& element of the cryptographic group  \\
      &	$\mid$	& \lst{Box} 				& value in a box protected by proposition  \\
      &	$\mid$	& \lst{AvlTree} 			&  Authenticated Dynamic Dictionary \\
      &	$\mid$	& $(\tau_1, \dots, \tau_n) $	& binary product type  \\
      & $\mid$  & $\text{\lst{Coll}}[\tau]$	& collection type       \\
      & $\mid$  & $\text{\lst{Option}}[\tau]$	& optional value (either $Some(\tau)$ or $None$)      \\
      & $\mid$  & \lst{Any}                     & type of any value (common supertype of all the types) \\
\end{tabular}\]

}

\end{document}


\documentclass[modern]{aastex62}

\pdfoutput=1

\usepackage{lmodern}
\usepackage{microtype}
\usepackage{url}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{natbib}
\usepackage{multirow}
\usepackage{graphicx}
\bibliographystyle{aasjournal}

% Matrix fix:
% http://tex.stackexchange.com/questions/317824/letter-c-appearing-inside-pmatrix-environment-with-aastex
\makeatletter
\def\env@matrix{\hskip -\arraycolsep\let\@ifnextchar\new@ifnextchar\array{*{\c@MaxMatrixCols}c}}
\makeatother

% Column spacing in matrix
% http://tex.stackexchange.com/questions/275725/adjusting-separation-between-matrix-entries
\setlength\arraycolsep{25pt}

% ------------------ %
% end of AASTeX mods %
% ------------------ %

% Projects:
\newcommand{\project}[1]{\textsf{#1}}
\newcommand{\kepler}{\project{Kepler}}
\newcommand{\ktwo}{\project{K2}}

% references to text content
\newcommand{\documentname}{\textsl{Note}}
\newcommand{\figureref}[1]{\ref{fig:#1}}
\newcommand{\Figure}[1]{Figure~\figureref{#1}}
\newcommand{\figurelabel}[1]{\label{fig:#1}}
\renewcommand{\eqref}[1]{\ref{eq:#1}}
\newcommand{\Eq}[1]{Equation~(\eqref{#1})}
\newcommand{\eq}[1]{\Eq{#1}}
\newcommand{\eqalt}[1]{Equation~\eqref{#1}}
\newcommand{\eqlabel}[1]{\label{eq:#1}}

% TODOs
\newcommand{\todo}[3]{{\color{#2}\emph{#1}: #3}}
\newcommand{\dfmtodo}[1]{\todo{DFM}{red}{#1}}
\newcommand{\alltodo}[1]{\todo{TEAM}{red}{#1}}
\newcommand{\citeme}{{\color{red}(citation needed)}}

% math
\newcommand{\T}{\ensuremath{\mathrm{T}}}
\newcommand{\dd}{\ensuremath{ \mathrm{d}}}
\newcommand{\unit}[1]{{\ensuremath{ \mathrm{#1}}}}
\newcommand{\bvec}[1]{{\ensuremath{\boldsymbol{#1}}}}
\newcommand{\Gaussian}[3]{\ensuremath{\frac{1}{|2\pi #2|^\frac{1}{2}}
            \exp\left[ -\frac{1}{2}#1^\top #2^{-1} #1 \right]}}

% VECTORS AND MATRICES USED IN THIS PAPER
\newcommand{\Normal}{\ensuremath{\mathcal{N}}}
\newcommand{\mA}{\ensuremath{\bvec{A}}}
\newcommand{\mC}{\ensuremath{\bvec{C}}}
\newcommand{\mS}{\ensuremath{\bvec{\Sigma}}}
\newcommand{\mL}{\ensuremath{\bvec{\Lambda}}}
\newcommand{\vw}{\ensuremath{\bvec{w}}}
\newcommand{\vy}{\ensuremath{\bvec{y}}}
\newcommand{\vt}{\ensuremath{\bvec{\theta}}}
\newcommand{\vm}{\ensuremath{\bvec{\mu}(\bvec{\theta})}}
\newcommand{\vre}{\ensuremath{\bvec{r}}}
\newcommand{\vh}{\ensuremath{\bvec{h}}}
\newcommand{\vk}{\ensuremath{\bvec{k}}}

% typography obsessions
\setlength{\parindent}{3.0ex}

\begin{document}\raggedbottom\sloppy\sloppypar\frenchspacing

\title{%
Robust characterization and detection of multi-planet radial velocity
exoplanet systems
Characterization of radial velocity exoplanets in multi-planet systems using
gradient-based inference
}

\author[0000-0002-9328-5652]{Daniel Foreman-Mackey}
\affil{Center for Computational Astrophysics, Flatiron Institute, New York, NY}

\author{others}

\begin{abstract}

RVs are rad.
High-dimensional MCMC is Hard.

\end{abstract}

\keywords{%
methods: data analysis ---
methods: statistical
}

\section{Introduction}

Many new high-precision spectrographs are coming online (list some examples)
with the explicit goal of detecting and characterizing exoplanet systems.
In many of these cases, these exoplanets will live in multi-planet systems
with more than one detectable Keplerian signal in the radial velocity time
series.
It is standard practice to characterize these signals in a Bayesian framework
(e.g.~radvel) where inferences are made about the properties of the system
using a probabilistic model and Markov chain Monte Carlo (MCMC).
Since MCMC is an iterative method, it must be run until convergence to obtain
robust results.
The number of computations required to reach convergence for multi-planet
systems using standard methods (e.g.~emcee) is prohibitively large since the
computational cost per independent sample scales as a high power of the number
of dimensions.

Instead, if we can compute the gradient of the log probability function with
respect to the parameters of the model, we can use gradient-based methods in
the Hamiltonian Monte Carlo (HMC) class of algorithms.
These methods generally scale better to large numbers of parameters---and we
will demonstrate that the same is true for radial velocity exoplanets.

\section{A probabilistic model of radial velocity exoplanets \& its gradients}

The radial velocity signature of an exoplanet orbiting its host star is seen
as a periodic trend in the radial velocity of the star's center of mass
induced by the orbit of the exoplanet.
Ignoring the mutual interactions between planets in the same system, we can
model the orbit as Keplerian and the mean model describing the radial velocity
curve of an $N$-body exoplanet system as a function of the physical parameters
of the planets is given by CITE EXOPLANETS \citep{Fulton:2018}
\begin{eqnarray}
v_r(t) &=& \sum_{n=1}^N K_n\,\left[ \cos(\nu_n(t)+\omega_n)
    + e_n\,\cos(\omega_n) \right]
\end{eqnarray}
where the sum is over the exoplanets $n=1,\ldots,N$, $K_n$ is the radial
velocity semi-amplitude, $e_n$ is the eccentricity, $\omega_n$ is the argument
of periastron, and $\nu_n(t)$ is the true orbital anomaly at time $t$ for
planet $n$.
The true anomaly is computed from the eccentric anomaly $E_n(t)$,
\begin{eqnarray}
\nu_n(t) &=& 2\,\tan^{-1}\left(\sqrt{\frac{1+e_n}{1-e_n}}\,
    \tan \frac{E}{2}\right)
\end{eqnarray}
which is, in turn, computed by numerically solving Kepler's equation for a
given mean anomaly $M_n(t) = 2\,\pi\,[t-t_{0,n}]/P_n$
\begin{eqnarray}
M_n(t) &=& E_n(t) - e \, \sin E_n(t)
\end{eqnarray}
where $P_n$ is the orbital period and $t_{0,n}$ is a reference time.

\section{Keplerian radial velocity exoplanet models \& their gradients}

The main step in this model that is not trivially differentiable in a standard
automatic differentiation framework is the solver for Kepler's equation.
We must solve Kepler's equation
\begin{eqnarray}
M = E - e\,\sin E
\end{eqnarray}
for the eccentric anomaly $E$ given some mean anomaly $M$ and eccentricity
$e$.
This can be solved numerically using standard methods (cite), but if we want
to use gradient-based methods, we must also be able to compute the gradients
$\dd E / \dd M$ and $\dd E / \dd e$.
These can be calculated by implicitly differentiating the above equation to
find
\begin{eqnarray}
\dd M &=& (1 - e\,\cos E)\,\dd E - \sin E \, \dd e \\
\dd E &=& \frac{1}{1 - e\,\cos E}\,\dd M + \frac{\sin E}{1 - e\,\cos E}\,\dd e
\end{eqnarray}
giving the required partial derivatives
\begin{eqnarray}
\frac{\dd E}{\dd M} &=& \frac{1}{1 - e\,\cos E} \\
\frac{\dd E}{\dd e} &=& \frac{\sin E}{1 - e\,\cos E} \quad.
\end{eqnarray}

\section{Outline}

Radvel \citep{Fulton:2018}

\bibliography{rvhmc}

\end{document}


%!TEX root = ../../dissertation.tex

\section{A recursive two-country economy}
\label{sec:model}

We study an exchange version of the \citet{Backus1994-bi}
two-country business cycle model.
Like their model, ours has
two agents (one for each country),
two intermediate goods (``apples'' and ``bananas''),
and two final goods (one for each country).
Unlike theirs, ours has
(i)~exogenous output of intermediate goods,
(ii)~a unit root in productivity,
(iii)~recursive preferences,
and (iv)~stochastic volatility in productivity growth in one country.
The first is for convenience.
The second allows us to produce realistic asset prices.
We focus on the last two, specifically their role in the fluctuations in
consumption and exchange rates.

{\textit Preferences.\/} We use the recursive preferences developed by
\citet{Epstein1989-mt,Kreps1978-gf}, and \citet{Weil1989-vy}.
Utility from date $t$ on in country $j$ is denoted $U_{jt}$.
We define utility recursively with the time aggregator $V$:
\begin{eqnarray}
    U_{jt} &=& V [c_{jt}, \mu_{t} (U_{jt+1})]
            \;\;=\;\; [(1-\beta) c_{jt}^{\rho} + \beta \mu_{t} (U_{jt+1})^{\rho}]^{1/\rho} ,
            \label{eq:time-agg}
\end{eqnarray}
where $c_{jt}$ is consumption in country $j$ and $\mu_t$ is a certainty equivalent function.
The parameters are $ 0 < \beta < 1$ and $\rho \leq 1$.
We use the power utility certainty equivalent function,
\begin{eqnarray}
    \mu_{t} (U_{jt+1} ) &=&  \big[ E_t  (U_{jt+1}^{\alpha} ) \big]^{1/\alpha} ,
%            \;\;=\;\; \Big[ \sum_{s_{t+1}} \pi(s_{t+1} | s^t) U_{j} (s^{t+1})^{\alpha} ) \Big]^{1/\alpha}
            \label{eq:cert-equiv}
\end{eqnarray}
where $E_t$ is the expectation conditional on the state at date $t$
and $\alpha \leq 1$.
Preferences reduce to the traditional additive case when $\alpha = \rho$.

Both $V$ and $\mu$ are homogeneous of degree one (hd1).
The two functions together have the property that if consumption is constant at $c$ from date $t$ on,
then $U_{jt} = c$.

In standard terminology, $ 1/(1-\rho)$ is the intertemporal elasticity of substitution (IES)
(between current consumption and the certainty equivalent of future utility)
and $1-\alpha$ is risk aversion (RA) (over future utility).
The terminology is somewhat misleading, because changes in $\rho$ affect future utility,
the thing over which we are risk averse.
As in other multi-good settings, there's no clean separation between risk aversion
and substitutability.

{\textit Technology.\/}
Each country specializes in the production of its own intermediate good,
``apples'' in country 1 and ``bananas'' in country 2.
In the exchange case we study, production in country $j$ equals its exogenous productivity:
\begin{eqnarray}
    y_{jt} &=&  z_{jt} .
            \label{eq:production}
\end{eqnarray}
Intermediate goods can be used in either country.
The  resource constraints are
\begin{eqnarray}
    a_{1t} + a_{2t} &=& y_{1t}
            \label{eq:resource-a} \\
    b_{1t} + b_{2t} &=& y_{2t}  ,
            \label{eq:resource-b}
\end{eqnarray}
where $b_{1t}$ is the quantity of country 2's good imported by country 1
and $a_{2t}$ is the quantity of country 1's good imported by country 2.

Agents consume final goods, composites of the intermediate goods defined by the
Armington aggregator $h$:
\begin{eqnarray}
    c_{1t} &=& h (a_{1t}, b_{1t} )
            \;\;=\;\; \big[(1-\omega) a_{1t}^{\sigma} + \omega b_{1t}^{\sigma}\big]^{1/\sigma}
            \label{eq:armington-1} \\
    c_{2t} &=& h (b_{2t} , a_{2t})
            \label{eq:armington-2}
\end{eqnarray}
with $ 0 \leq \omega \leq 1$ and $\sigma \leq 1$.
The elasticity of substitution between the two intermediate goods is $1/(1-\sigma)$.
The function $h$ is also hd1.

We will typically use $\omega < 1/2 $, which puts more weight on the home good
in the production of final goods.
This ``home bias'' in final goods production is essential.
If $\omega = 1/2$, the two final goods are the same.
In this case, we have identical hd1 utility functions,
and any optimal allocation
involves a constant Pareto weight and proportional consumption paths.

{\textit Shocks.\/}
Fluctuations in this economy reflect variation in
the productivities cum endowments $z_{jt}$ and the conditional variance of the first one.
Logs of productivities have unit roots and are cointegrated:
\begin{eqnarray}
    \left[
    \begin{array}{c}
    \log z_{1t+1} \\ \log z_{2t+1}
    \end{array}
    \right]
    &=&
    \left[
    \begin{array}{c}
    \log g \\ \log g
    \end{array}
    \right] +
    \left[
    \begin{array}{cc}
    1-\gamma & \gamma \\ \gamma & 1-\gamma
    \end{array}
    \right]
    \left[
    \begin{array}{c}
    \log z_{1t} \\ \log z_{2t}
    \end{array}
    \right] +
    \left[
    \begin{array}{c}
    v_t^{1/2} w_{1t+1} \\ v^{1/2} w_{2t+1}
    \end{array}
    \right] ,
    \label{eq:lom-z}
\end{eqnarray}
with $0 < \gamma < 1/2$.
The only asymmetry in the model is the conditional variance
of productivity.
The conditional variance $v$ of $\log z_{2t+1}$ is constant.
The conditional variance $v_t$ of $\log z_{1t+1}$ is AR(1):
\begin{eqnarray}
        v_{t+1} &=& (1-\varphi_v) v + \varphi_v v_t + \tau w_{3t+1} .
        \label{eq:lom-v}
\end{eqnarray}
The innovations $\{ w_{1t}, w_{2t}, w_{3t} \} $ are standard normals
and are independent of each other and over time.


\section{Thesis Overview}

In this section, I provide a brief overview of this dissertation. The introduction, the thesis overview, and the list of publications are given in~\textbf{\ChapRef{intro}} (this chapter). \textbf{\ChapRef{prelim}} introduces definitions and notations, together with well-established facts about mathematical structures that are used throughout the thesis. The rest of the work is split into four parts. Each part corresponds to a separate research area that I contributed to during my doctoral studies.

\subsection{\PartRef{str}. Structural and Decomposition Cryptanalysis}

In this part, I present my contribution to structural and decomposition cryptanalysis and S-Box reverse-engineering. It consists of three chapters.

\textbf{\ChapRef{feistel}} shows an application of structural cryptanalysis to the Feistel Network structure. Our research emerged from observing interesting patterns in the linear approximation table of 4- and 5-round Feistel networks with tiny block size. The linear approximation table is used to measure the resistance of the structure to linear cryptanalysis (see Section~\ref{prelim.sec:lindiff} of \ChapRef{prelim}). By studying the artifacts, we deduced and proved their relation to integral cryptanalysis. Further, we generalized and proved these integral properties of Feistel networks. As a result, we obtained a simple closed formula on the number of rounds of Feistel networks, when the integral distinguisher is possible. We represented the integral distinguishers in the form of the \emph{high-degree indicator matrix} (HDIM). Further, we showed the usefulness of HDIM as a tool by cryptanalyzing Feistel networks composed with random affine layers. In addition, we proposed a decomposition attack on Feistel networks based on the integral distinguishers.

\textbf{\ChapRef{kuz}} describes decompositions of the S-Box used in the recent Russian cryptographic standard. With my coauthors, we discovered interesting and unique structures of the S-Box based on the finite field arithmetic. In the chapter, I describe the step-by-step decomposition process. The methods developed in this work will prove their usefulness in~\ChapRef{apn}.

\textbf{\ChapRef{apn}} shows the decomposition of the only known APN permutation in even dimension. APN stands for \emph{almost perfect nonlinear} and corresponds to optimal resistance against differential cryptanalysis. The existence of APN permutations in even dimensions was a long-standing problem until the 6-bit APN permutation was published by Dillon~\etal in 2009. Since then, no new significant progress on the problem was achieved. Furthermore, the method that was used to find the S-Box does not provide any insight on how to generalize the APN permutation. With Alex Biryukov and Léo Perrin, we applied the methods of S-Box reverse-engineering to this S-Box of mathematical origin and surprisingly discovered an interesting structure, which we called a \emph{butterfly}. We studied its properties and generalized it to higher dimensions. Even though we did not find any new APN permutation in even dimension, the generalized butterfly is only slightly weaker than APN permutations.

\subsection{\PartRef{ni}. Nonlinear Invariants}

In this part, I describe my contribution to the method of cryptanalysis based on nonlinear invariants. It consists of two chapters.

\textbf{\ChapRef{norx}} describes an analysis of the core permutation of the NORX authenticated encryption scheme, a third round CAESAR candidate. First, I describe invariant subspaces of the permutation obtained from rotational symmetry of the structure. Second, I show probabilistic invariant subspaces obtained from rotational word symmetry. To illustrate the dangers of such properties, I describe two attacks on slightly modified variants of NORX. Further, I provide the cycle decomposition of a 32-bit mapping $G$ used in the NORX8 instance. I propose an algorithm for the search of low-degree non-linear invariants from a cycle decomposition and apply it to $G$. The results show that there are no low-degree invariants of $G$ holding with probability one. This chapter is based on the joint work~\cite{OurNORX} with Alex Biryukov and Vesselin Velichkov, which is currently available as an online report.

\textbf{\ChapRef{linear}} shows a theoretical study of linear layers that preserve a particular class of low-degree invariants. It is a generalization of the theorem from~\cite{NonlinInv}, where it was shown that orthogonal linear layers preserve a particular class of quadratic invariants. Our study shows that no \emph{bijective} linear layers preserve a similar class of cubic invariants. However, there are such \emph{expanding} linear layers. The linear layers that are studied, correspond to subsets of $\field{n}$ on which every Boolean function of algebraic degree at most $d$, sums to zero. Furthermore, these sets of vectors must have full rank. We call them degree-$d$ zero-sum sets of full rank. The rest of the chapter is devoted to studying the minimum possible size of such sets. This size is related to the minimum expansion rate of the corresponding linear layers. I describe several nontrivial bounds for the minimum possible size of full-rank degree-$d$ zero-sum sets. This chapter is based on the joint work~\cite{OurNLI} with Christof Beierle and Alex Biryukov, which is in the process of submission to a Boolean function journal.

\subsection{\PartRef{wb}. White-box Cryptography}

In this part, I describe my contribution to symmetric cryptography in the white-box model. This part is based on the joint work~\cite{OurWhitebox} with Alex Biryukov. It consists of two chapters.

\textbf{\ChapRef{wba}} describes several attacks on white-box implementations using masking schemes. Recently, Bos~\etal~\cite{AttackBos} showed that most public white-box implementations can be broken in an automated way by a classic side-channel attack.
It is therefore natural to apply side-channel protection - masking - to protect white-box implementations. However, this chapter shows many caveats that appear in the white-box setting. The described attacks result in constraints that a secure white-box implementation based on masking has to satisfy. In particular, the classic Boolean masking of any order is not secure since it is a linear scheme.

\textbf{\ChapRef{wbc}} describes a general methodology for securing a white-box implementation. The attacks are split into two groups, and each group corresponds to a separate component of protection. The two components are called \emph{structure hiding} and \emph{value hiding}. Structure hiding protection must hide structural patterns and prevent locating of critical computation points in the circuit by graph-based analysis. It also should include protection against fault attacks, though this may be considered as a separate component. Value hiding protection must prevent  attacks based on analysis of values computed in the white-box circuit, such as side-channel power analysis attacks. In our research, we focused on the value hiding protection, in particular on the novel attack against Boolean masking. We develop a security model and a game-based security definition. Further, we develop a framework of provable security against the attack. Finally, we propose a novel quadratic masking scheme instantiating the developed framework of provable security. We implement AES-128 encryption protected by the novel masking scheme together with the classic Boolean masking scheme to estimate the overhead.

\subsection{\PartRef{de}. Symmetric Algorithm Design}

In this part, I describe my contribution to the design of symmetric-key algorithms. It consists of two chapters.

\textbf{\ChapRef{sparx}} describes SPARX, a lightweight block cipher designed by my colleagues and me. The cipher follows a novel design strategy called a \emph{long-trail strategy}. This strategy provides provable security against single-trail linear and differential cryptanalysis for ARX-based structures, where the classic \emph{wide-trail} strategy is not efficient. I developed two algorithms for long-trail evaluation of a given structure. We evaluated a large class of linear layer structures for the block cipher. During the evaluation, my algorithms were used in order to measure the resistance of the linear layer against linear and differential attacks. I also evaluated the linear layer candidates for resistance against integral attacks using the division property, a state-of-the-art technique. The final choice was done by finding an optimal ratio between the two parameters, and also considering implementation properties. It turned out that a linear Feistel round leads to the best compromise between the parameters. This chapter is based on the joint work~\cite{OurSPARX} with Daniel Dinu, Léo Perrin, Vesselin Velichkov, Johann Großschädl, and Alex Biryukov.

\textbf{\ChapRef{sparkle}} describes a suite of symmetric-key algorithms. SPARKLE is a family of three cryptographic permutations motivated by the SPARX design. ESCH is a family of two hash functions built using the sponge construction and the SPARKLE permutations. SCHWAEMM is a family of authenticated encryption algorithms, built using the recent Bettle sponge-based mode and the SPARKLE permutations. I performed various analyses of the SPARKLE permutation and its components, including nonlinear invariant analysis, a linearization study of the ARX-based S-Box, evaluation of resistance against integral attacks. Furthermore, I propose a generic algorithm for building the matrix of transitions of truncated differential trails through the linear layer. The algorithm takes as input the binary matrix of the linear layer and computes precise probabilities. The advantage of this method is that it automatically takes into account all dependencies between computations in the linear layer, helping to avoid possible mistakes. Finally, I propose several attacks on reduced-round versions of SCHWAEMM. The suite of primitives is submitted to the NIST Call for Lightweight Cryptographic Algorithms~\cite{NISTlight}. It is a joint work with Christof Beierle, Alex Biryukov, Luan Cardoso dos Santos, Johann Großschädl, Léo Perrin, Vesselin Velichkov and Qingju Wang.