% \section{System Design}
\section{Confidential Contract}

Phala Network aims to build a platform for general-purpose privacy-preserving Turing-Complete smart contracts. The basic requirements for such a platform could be as follows.

\begin{icompact}
    \item \textbf{Confidentiality.}
    Unlike the existing blockchains for smart contracts, Phala Network avoids the leakage of any input, output, or intermediate state of confidential contract. Only authorized queries to the contract will be answered.

    \item \textbf{Code Integrity.}
    Anyone can verify that an output is produced by a specific smart contract published on the blockchain.

    \item \textbf{State Consistency.}
    Anyone can verify that an execution happened at a certain blockchain height, which implies the output of the execution is subject to a certain chain state.

    \item \textbf{Availability.}
    There must not be a single point of failure such as disconnection of the miner.

    \item \textbf{Interoperability.}
    Contracts can interoperate with each other and external blockchains.
\end{icompact}

The existing TEE solutions, e.g., Intel SGX, can only prevent the leakage of sensitive information during the execution of \textit{isolated} programs, and provide no guarantee on availability or verification of input data. Thus it requires a carefully-designed infrastructure to integrate TEE into blockchain to meet the requirements above.

We are going to introduce the design of Phala Network and how it fulfills the above requirements in the following sections.

\subsection{Abstraction of Confidential Contract}

A typical smart contract can be regarded as a state machine of a current state $s_n$ and a state transition function $f$, which takes input event $e_n$ and last state $s_{n-1}$ to produce the latest state $s_n$:

$$
    s_n = f(s_{n-1}, e_n)
$$

Since the state transition process happens inside the enclave, any of its intermediate states remains invisible to outside.
We can further encrypt the reached state and input event to prevent the attackers from inferring the internal state of contract with event replay.

Let $cs_n$ be the cipher of $s_n$ and $ce_n$ be the cipher of $e_n$, the state transition function of a confidential contract $p$ can be represented as:

\begin{align}
    cs_n              & = p(cs_{n-1}, ce_n)                                                             \\
    p(cs_{n-1}, ce_n) & = \mathrm{Enc}\bigg(f\big(\mathrm{Dec}(cs_{n-1}), \mathrm{Dec}(ce_n)\big)\bigg)
\end{align}

where $\mathrm{Enc}$ and $\mathrm{Dec}$ can be carefully-chosen symmetric encryption and decryption functions subject to the contract.

Unlike the existing smart contract, a confidential contract doesn't expose any information outside the enclave by default. To answer authorized queries, we introduce a query function $q$ which takes the current encrypted state $cs_n$, query parameters $paras$ and user's identity $I$ (usually a pubkey) as input and returns the response $r$:

$$
    r = q(cs_n, paras, I)
$$

The confidential contract must first validate the identity of the user and then respond to her query. Apart from the queries from users, the contract may also accept a special query producing side effects. The side effects include the egressing data that can be posted back to the blockchain by miners.

\section{The Protocol}

\begin{figure}[!t]
    \centering \footnotesize
    \includegraphics[width=\columnwidth]{img/pLIBRA-roles}
    \caption{Roles in the protocol.}
    \label{fig:roles}
\end{figure}

There are a few roles involved in the protocol as shown in Figure~\ref{fig:roles}.

\begin{icompact}
    \item \textbf{Users.}
    Users invoke, query and deploy smart contracts. Users interact with smart contracts via \textbf{Blockchain} and \textbf{Worker Nodes}. They can verify the blockchain as well as the cryptographic evidence on the blockchain independently by running a light client or full node. No special hardware, i.e., TEE, is needed for users to use the confidential contracts.
    \item \textbf{Worker Nodes.}
    Worker Nodes run confidential contracts in TEE-compatible hardwares. Worker Nodes are off-chain. In each node, a special program called \pruntime is deployed to the enclave. The runtime has a builtin VM to run contracts. It also cooperates with the blockchain to support the contracts in full life cycle. Worker Nodes can be further divided into three roles:
    \begin{icompact}
        \item \textbf{Genesis Node.}
        Genesis Node helps bootstrap the network and set up the cryptographic configuration. There's only one Genesis Node and it's destroyed after the launch of Phala Network.
        \item \textbf{Gatekeepers.}
        Gatekeepers manage the secrets to ensure the availability and security of the network. Gatekeepers are dynamically elected on the blockchain and they stake a large amount of Phala token. They are rewarded for being online and slashed in case of misbehavior because there must be a certain number of functional Gatekeepers running at any time.
        \item \textbf{Miners.}
        Miners execute the confidential contracts. They get paid by providing their computing resources to the users. Unlike Gatekeepers, Miners only need to stake a small amount of the Phala token and can join and exit the network as they want.
    \end{icompact}
    \item \textbf{Remote Attestation Service.}
    Remote Attestation Service is a public service to validate if a Worker Node has deployed \pruntime correctly. The cryptographic evidence produced by the service can prove a certain output is produced by \pruntime running inside a TEE. IAS~\cite{ias} is Intel SGX's remote attestation service implementation.
    \item \textbf{Blockchain.}
    Blockchain is the backbone of Phala Network. It stores the identities of the Worker Nodes, the published confidential contracts, the encrypted contract state, and the invocation transactions from users and other blockchains. When plugged into a Polkadot parachain slot, it's capable to interoperate with other blockchains through the Polkadot relay chain.
\end{icompact}

\subsection{System Design}

We first propose an important property which works as the basis of the following system design.

\noindent {\bf All worker nodes are non-Byzantine nodes.}
As illustrated above, each worker node runs a special program \pruntime in its TEE. The \pruntime, as the name suggests, works as the runtime environment for confidential contracts. It exports a set of APIs for contracts to access the state resources, manages the connections to the blockchain and answers user queries securely.
\pruntime implements the Phala Network protocol described in this paper. Since the integrity of \pruntime is guaranteed by the remote attestation service, this isolation promises that no Byzantine fault can happen unless both the TEE and \pruntime are compromised, and an adversarial worker node can only launch a Denial-of-Service attack, which can be further detected by our responsiveness monitoring protocol.

In our system, the executors, i.e., miners, are stateless, which means the latest state of a confidential contract has to be got by sequentially executing all the input events on the blockchain or from a cached contract state and the events after that. All the inputs have to be first published to the blockchain and in this way, the blockchain works as the canonical source of contract inputs, which implies \textit{Event Sourcing} design pattern. We further utilized the idea of \textit{CQRS} in the design of the protocol to accelerate the users' queries to the contracts.

\pruntime maintains a set of secrets durning its life cycle. Contract states are encrypted and checkpointed on the blockchain with a symmetric key. Each \pruntime registers its identity on the blockchain and establishes secure connections to users with an asymmetric key pair. Since each \pruntime registers itself on the blockchain, any user can validate its identity. These secrets never go outside the \pruntime.

\subsection{Node Registration}

All the Worker Nodes are required to be registered on the blockchain before participating in mining or Gatekeeper election.

Remote attestation provides a building block to verify the execution as well as its output of a certain code inside the enclave. However, running such attestation on each execution is time inefficient. In Phala Network we adopt a better protocol. The attestation measures the \pruntime instance and the generated unique identity during the registration, instead of each execution. In this way, a single attestation is sufficient to ensure the future behavior of the \pruntime.

\begin{figure}
    \centering \footnotesize
    \includegraphics[width=.7\columnwidth]{img/pLIBRA-communication}
    \caption{RA and communication.}
    \label{fig:communication}
\end{figure}

\begin{enumerate}
    \item The host program of the worker node $n$ (i.e.\,Miner or Gatekeeper) calls \texttt{pRuntime.GetIdentity} to generate a key pair as an identity $I_n(pk_n, sk_n)$.  $sk_n$ is kept inside the enclave and $pk_n$ is revealed to the host.

    \item The host calls \texttt{pRuntime.GetRAQuote} to generate a remote attestation quote $q$ with the commitment to $pk_n$ and other necessary metadata.

    \item The host submits $q$ to Remote Attestation Service and get the signed quotes $q_{signed}$.

    \item The host submits $(q_{signed}, pk_n)$ to the blockchain. The blockchain then accepts and stores the information after validation.
\end{enumerate}

The registered \pruntime instances are non-Byzantine. The \pruntime instance and the generated identity is measured by the attestation. It implies \pruntime runs in a TEE and the identity is generated securely. Since the privkey is unknown to any party expect the instance, nobody can pretend to be a registered \pruntime.

With the identity registered, a TLS-like channel between the requester and the target \pruntime can be established. The identities published on the blockchain serve as the PKI to avoid MitM attack. As the \pruntime is non-Byzantine in such a communication channel, the \pruntime can be trusted without further need of remote attestation.  This trick improves the efficiency and flexibility of code execution in the runtime.

The metadata contains other necessary information, for example, the network endpoint of the node like libp2p multiaddrs. The registration has an expiration date to prevent vulnerabilities discovered in the future. Worker nodes can renew it by redo the registration process including generating a new identity and do the remote attestation.

\subsection{State Encryption}

Confidential contract runs on \pruntime and the states are persisted on the blockchain to ensure the availability. As the information on the blockchain are public, the saved states have to be encrypted. In Phala Network, each contract ($c_i$) is associated with a symmetric key called \textbf{Contract Key} ($k_{c_i}$).

Contract keys are generated by Gatekeepers inside \pruntime. To run a contract, a registered miner should get the corresponding contract key from Gatekeepers. The miner reads the latest contract states and decrypt it with the contract key during initialization. Then the updated states are encrypted and saved to the blockchain in the future. Gatekeepers hold the contract keys as a part of their states. Gatekeepers share a symmetric key called \textbf{Root Key} ($k_r$). The Gatekeeper states are also encrypted and saved to the blockchain like miners. All the keys are used by and kept in \pruntime.

The details of key management are discussed in below subsections. We further propose a few improvements including key rotation (in ``Key Rotation'' subsection) and a distributed key generation (DKG) scheme in ``Open Questions'' section.

\subsection{Blockchain Launch}

In the blockchain launch phase, the blockchain will load the initial distribution of the native token and start the election of Gatekeepers. A Genesis Node assists the launch of the blockchain.

\begin{enumerate}
    \item Before the genesis block, the Genesis Node runs \texttt{pRuntime.Bootstrap} to generate a key pair as the identity of the node, and a symmetric key, namely Genesis Identity $I_g(pk_g, sk_g)$ and the genesis Root Key $k_r^{(0)}$. The runtime reveals $pk_g$ but keeps $sk_g$ and $k_r^{(0)}$ privately.

    \item Start the blockchain with $pk_g$. In this stage $pk_g$ is published in the genesis block and is used for other worker nodes to establish secure channels to the Genesis Node. $k_r^{(0)}$ is kept inside the Genesis Node and is used to store secrets necessary to run the network on the blockchain. The initial native token distribution is loaded in the genesis block.

    \item The blockchain is at pre-launch phase after the genesis block. Governance module is enabled but other modules including confidential contract are still disabled until the Gatekeepers are elected.

    \item Worker Nodes who want to participate in Gatekeeper election can follow the \textbf{Node Registration} scheme to register their identities on the blockchain. Then $n_{gatekeepers}$ (a chain parameter between tens to hundreds) Gatekeepers will be elected during the pre-launch phase. This can be done on-chain via an Polkadot-style NPoS validator election (see Appendix II for details).

    \item When the election is finished, the Gatekeepers send a request to the Genesis Node for $k_r^{(0)}$ through a TLS connection. The Genesis Node only answers the requests from the selected Gatekeeper. Gatekeepers confirms their readiness the on the blockchain.

    \item The Genesis Node retires and self destroys when it sees the confirmations of the Gatekeepers from the blockchain. In case there are unresponsive Gatekeepers, the election will expire and restart after the deadline.
\end{enumerate}

So far Gatekeepers have their identity registered on the blockchain and $k_r^{(0)}$ has been distributed to all the Gatekeepers' runtime. Then $k_r^{(0)}$ will be used to deploy nodes and contracts in the future.

Periodical key rotation is necessary for forward secrecy. The root key at era $n$ is denoted by $k_r^{(n)}$. We will discuss the details in ``Key Rotation'' subsection.

\subsection{Deploy Worker Nodes}

Both miners and Gatekeepers have to follow the ``Node Registration'' scheme to join the network. The protocol ensures the nodes are non-Byzantine. So we only consider responsiveness failures. To ensure the service quality, all the worker nodes must stake a certain amount of the Phala token and \textbf{could be slashed} once it fails to meet the responsive requirements. We will discuss the details about staking and monitoring in ``Responsiveness Monitoring'' section.

As Gatekeepers store the root key and need to be always online, they have to meet a higher standard and need to stake a larger amount. They are rewarded for keeping online and could be slashed otherwise.

\subsection{Deploy the Contract}

The bytecode of the compiled contract is published on the blockchain and then loaded by a user-specified miner to its \pruntime. The Gatekeepers generate a symmetric encryption key for each newly published contract. The key is shared with the corresponding \pruntime for state encryption. More specifically:

\begin{enumerate}
    \item The developer publish the contract $c_i$ to the blockchain
    \item Once Gatekeepers notice the publish of $c_i$, they generate a corresponding contract key $k_{c_i}$ for contract states encryption.
    \item Gatekeepers save $k_{c_i}$ to the blockchain as a part of the chainstate encrypted with Root Key $k_r^{(n)}$
    \item The developer finds an available miner to load the contract. The developer can either run his miner so that no extra fee is needed, or rent one from a resource market (see ``Economic Design Paper'' for more details).
    \item The miner runtime connects to Gatekeeper through a secure connection and asks for $k_{c_i}$ by \texttt{pRuntime.GetContractKey}.
\end{enumerate}

The miner's \pruntime will use $k_{c_i}$ to encrypt the contract state and save it to the blockchain periodically. We will discuss the details in ``Execute the Contract'' and ``State Recover'' section.

\subsection{Key Rotation}

The Gatekeepers are re-elected in each era according to the election rule (Appendix II). While rotating the Gatekeepers, the root key is also rotated. Let $G_{n-1}$ and $G_n$ be the Gatekeepers set before and after the election at era $n$. The root key will be rotated as follows:

\begin{enumerate}
    \item $G_n$ is elected on-chain by the governance module in the last block of each era. Simultaneously two leaders $l_{n-1} \in G_{n-1}$ and $l_n \in G_n$ are randomly chosen. The randomness comes from the random beacon in the block.
    \item Any communication between miners and Gatekeepers is blocked until the key rotation is done.
    \item Once the block is finalized, $l_{n-1}$ and $l_n$ collaboratively generate the next root key $k_r^{(n)}$ by a DH-like key exchange protocol with salts. $l_{n-1}$ decrypts the Gatekeeper states and re-encrypt with $k_r^{(n)}$ and save it to the blockchain. $l_n$ broadcasts $k_r^{(n)}$ to other members in $G_n$ by a secure communication channel. $G_n$ members will confirm the readiness on-chain when they received $k_r^{(n)}$.
    \item Once all the $G_n$ members have confirmed and $l_{n-1}$ has updated the Gatekeeper states, the blockchain will generate a ``Key Rotation Ready'' event so that miners can resume the communication with the new Gatekeepers. Simultaneously the $G_{n-1}$ members who are not still in $G_n$ will notice the event and perform self destruction.
    \item There's an expiration time for the key rotation procedure in case of the unresponsiveness. In such case, the unresponsive Gatekeepers will be slashed and the procedure should start over.
\end{enumerate}

All the off-chain key management and encryption is handled by the \pruntime of the Gatekeepers.

The key rotation protocol starts from the first block in an era and ends after the final on-chain confirmation. Durning this period no new contract can be deployed to the miners because the communication between miners and Gatekeepers is blocked. However the delay caused by the protocol is trivial compared with the length of an era. In the best case, the delay is 2 round-trip-time (two on-chain confirmations).

Contract keys can be rotated in a simpler way. The miner generates a new contract key and re-encrypt the states with the new key. Then it can send the new contract key to Gatekeepers in a secure channel, and save the states to the blockchain. The two actions are combined in a single transaction to make then atomic.

Root key and contract key rotation ensures the forward secrecy of the confidential state (for both Gatekeeper state and contracts state). The keys for the obsolete data are destroyed once the rotation is done.

\subsection{Execute the Contract}

We adopt an Event Sourcing / CQRS style architecture for the contract execution. Read queries and write commands are segregated.

The contract state is determined by the write commands which have multiple sources: user invocations, blockchain events, and ingressive messages from the relay chain. In a naive design, we ask all the write commands to be recorded explicitly on the blockchain. The commands are denoted by \textbf{Ingressive Events} to \pruntime. As the events on the blockchain are ordered naturally, the blockchain becomes a canonical source of events.

\begin{figure}
    \centering \footnotesize
    \includegraphics[width=.7\columnwidth]{img/pLIBRA-execute}
    \caption{Execute the contract.}
    \label{fig:contract-execution}
\end{figure}

\begin{enumerate}
    \item The miner (host) ingests the ingressive events to the runtime by calling \texttt{pRuntime.SyncBlockchain}. The incoming events are paired with cryptographic evidence which is validated by a light-weight Substrate client inside \pruntime. It ensures the integrity of the incoming events.
    \item The runtime picks out the events targeting the contract deployed inside and feeds the contract. The execution of the contract produces a view of the \texttt{Chainstate}, namely \texttt{Chainview}
    \item At any time, users can query \texttt{Chainview} by \texttt{pRuntime.Query}. The identity of the caller is attached to the queries so that the contract can decide whether to answer or not based on its customized authorization policy. The response to the query includes the query result as well as a commitment to the current blockchain state (e.g.\,height) and the contract state. In other words, all the outputs are subject to a certain blockchain state.
    \item The runtime also produces various side-effects which is accessible by \texttt{pRuntime.DumpSideEffect}. A basic kind of side-effect is the encrypted contract state update produced periodically by \pruntime. With the full contract state, a new miner doesn't need to sync the data by replaying the entire blockchain history. Another kind of side-effects is outgoing messages targeting other contracts or blockchains, namely \textbf{Egressing Events}. The ability to post messages to external entities is the building block for contract interoperability. The submitted events are eventually dispatched to the target contract, or other blockchains by the Polkadot ICMP (Interchain Message Passing, https://research.web3.foundation/en/latest/polkadot/ICMP/). Miners (host) are responsible to post the side-effects back to the blockchain.
\end{enumerate}

To invoke a contract the user needs to generate a shared secret key with the miner who runs the contract. This can be done via a non-interactive Diffie-Hellman key exchange scheme with her private key and the miner's registered public key~\cite{schindlerdistributed}. The key is used for future communication and then the user can submit the encrypted payload to the blockchain. The invocation events are processed by \pruntime once they arrive at the miner node.

As invocation payloads are included in a block, the blockchain is naturally a canonical source of events. All the contract invocations initiated by users, smart contracts, and other blockchains are timestamped and treated equally by the executor. It therefore makes a unified interface for contract interoperability.

The downside of the architecture is that the confirmation of the commands happens after the confirmation of the block. The performance of the blockchain becomes the bottleneck for contract invocations. However, the read-only queries are made into the runtime directly and the performance is not bounded by the blockchain. This is possible because the queries don't modify the contract state.

Miners are responsible to ensure the communication between \pruntime and the blockchain. A monitoring scheme is needed to ensure the connectivity. In the worst case (e.g.\,miner shutdown) the contract execution can be resumed by another miner.

\subsection{State Recover}

A single miner is sufficient to run a contract. Though miners are incentivized to run contracts in the long term, the miner may still becomes unresponsive due to network or power outage rarely. In such a case another miner can recover the saved state from the blockchain and resume execution.

As mentioned in section ``Execute the Contract'', one of the side-effects produced by \pruntime is the periodical contract state update. The dumped state is encrypted by $k_{c_i}$ and stored on the blockchain. In the case of miner unavailable, a new miner can recover the latest dumped contract state from the blockchain and decrypt it with $k_{c_i}$. After recovering the state, the runtime can further replay the rest of the events on the blockchain until reaches the chain tip.

\subsection{Responsiveness Monitoring}

Both Gatekeepers and miners are required to keep the responsiveness to keep the functionality of Phala Network. Gatekeepers have to maintain a high level of responsiveness because the root key is kept inside the Gatekeepers runtime and must be available at any time. As long as Gatekeepers can serve the contract key for miners, the availability of the contracts can be guaranteed. So unresponsive miners are not as harmful as unresponsive Gatekeepers to the system.

We adopt a Polkadot-like unresponsiveness detection algorithm~\cite{polkadotslashing}. Both Gatekeepers and miners produce side-effects by their runtime. They have to at least post the state updates periodically to the blockchain within an interval. So all the submitted side-effects can be used as a counter of the online activities. Then we can determine if a node $n$ is unresponsive in an era by
$$
    c_n < \frac{1}{4} \max\limits_{n'}{c_{n'}}
$$
where $c_n$ is the activity counter for node $n$ and $n'$ is all the connected worker nodes in the era. For the detailed design of slash, please refer to Economic Design Paper.

\section{Open Question}

Security improvements:

\begin{icompact}
    \item Alternative TEE hardware: Though we use Intel SGX as the reference for the current design, we don't make any assumptions about the hardware. Potential TEE hardware includes AMD SEV, ARM Turstzone, and some open-source implementations in progress. When we support any alternatives the different TEE can work together transparently.
    \item Threshold key sharing on Gatekeeper root keys: The confidentiality of all the confidential contracts is derived from the root key. However root keys are replicated among all the Gatekeepers in current design, meaning a compromised TEE could compromise the whole system. A more robust ways is to apply a threshold secret sharing scheme (e.g. Shamir's) on the root key. A distributed key generation scheme (DKG) can be used instead of selecting a leader to generate the key in the key rotation protocol.
    \item Contract key backup by secret sharing scheme: To avoid catastrophes where Intel SGX breaks entirely (e.g.\,Intel bans all the Remote Attestation request from our side), we can utilize a secret sharing scheme to distribute the Root Key to the Gatekeepers, or maybe two generations of the Gatekeepers. In such a case, we can wait for the deployment of an alternative TEE system. Then the secret holders can collaborate to ingest the key to recover the execution of Phala Network.
\end{icompact}

Optimizations:

\begin{icompact}
    % \item Event batching & async state commitment
    \item Redundant miners for a contract: Currently one contract is only associated with one miner. The state recovery still takes some time though the availability is guaranteed. With >1 miners, as the contract execution is deterministic, the miners can compete to run the contract and checkpoint the states on the blockchain. The blockchain can always accept new states and reject redundant submissions.
    \item State storage prune
    \item Layer 2 state sharing
\end{icompact}

\section{The First Application: pLIBRA}

pLIBRA is a free and privacy-preserving Libra Coin built on Polkadot. It includes

\begin{icompact}
    \item A bridge connecting Polkadot and Libra
    \item A privacy-preserving token pLIBRA 1:1 pegged to Libra Coin (KYC not needed)
    \item A confidential-preserving cross-chain interoperable DApp ecosystem for Libra users
\end{icompact}

\begin{figure}
    \centering \footnotesize
    \includegraphics[width=.7\columnwidth]{img/pLIBRA-structure}
    \caption{pLIBRA overview.}
    \label{fig:plibra}
\end{figure}

\subsection{System Design}

pLIBRA is implemented as a confidential contract on Phala Network. It implements a Libra light client and a ERC20-like token inside the confidential contract.

\begin{icompact}
    \item \textbf{Libra Light Client}: A full light client which is capable to validate the Merkle proof of the chain state and sign transactions.
    \item \textbf{Key Store}: Stores the private keys for the collateral Libra accounts (i.e.\,\textit{bank account}).
    \item \textbf{AccountDB}: Stores the pLIBRA accounts and the balance.
\end{icompact}

\begin{figure}
    \centering \footnotesize
    \includegraphics[width=.7\columnwidth]{img/pLIBRA-contract}
    \caption{pLIBRA Architecture.}
    \label{fig:plibra}
\end{figure}

Confidential contract allows the client to manage privkeys and sign transactions without utilizing computing-intensive cryptographic. Libra users can send their Libra Coin to pLIBRA's bank account and get 1:1 pLIBRA token and vice versa.

As the information of the pLIBRA accounts is hidden inside the enclave, the pLIBRA token gets privacy-preserving feature like Monero for free. Phala Network is designed to be launched as a parachain on Polkadot. So pLIBRA also gets the ability to interoperate with all the blockchains connected to Polkadot.

At the time of writing, Libra only has very limited smart contract functionality (only whitelisted contracts are allowed). So here we present a naive way to store Libra without the need to employ an advanced feature like multisig or smart contract. When the smart contract is launched on Libra, we can further improve the security of our design by adopting a multisig-style collateral.

\begin{icompact}
    \item \textbf{Init}. During the init phase, pLIBRA contract generates a key pair and reveal the public key. Then an account on Libra blockchain serving as the \textbf{Bank Account} is registered with the public key. This is a one-off task done by pLIBRA team. Note that pLIBRA team doesn't have any control over the bank account because the private key is always kept inside the confidential contract.
    \item \textbf{Sync}. The Libra light client is responsible to parse and validate the blockchain data from Libra network. Though at the beginning pLIBRA team will proxy Libra blockchain data to pLIBRA, the blockchain data can be fed by any user. We expect that the pLIBRA end-users will proxy the Libra blockchain data to get their transaction executed. This can be done by a shared library in the wallets. (Side notes: Libra doesn't have a typical ``blockchain'' data structure. By saying blockchain data, we refer to the Libra ledger updates.)
    \item \textbf{Link Account}. To deposit Libra to the system for pLIBRA, linking the accounts is needed. The user links the address of his Libra account and a pLIBRA account with the signature signed by the key pair of both accounts. It proves that both accounts are owned by the user. After the link operation, deposit and withdraw can only happen between the linked accounts.
    \item \textbf{Deposit}. The user sends some Libra coins to the \textbf{Bank Account} and tells pLIBRA the transaction. Once it's confirmed by the Libra light client inside the contract, the same amount of pLIBRA will be issued to the linked pLIBRA account.
    \item \textbf{Withdraw}. The user can request to withdraw pLIBRA. The requested amount of pLIBRA is burned and it will produce a transaction to release the same amount of Libra to the linked address. To broadcast the transaction to Libra network, the pLIBRA contract maintains a sequence of the tx. When the withdraw requester asks for his withdraw tx, it returns all the ``not yet executed'' tx. The requester has to broadcast all the pending tx until his tx are executed.
    \item \textbf{Transfer}. Transferring pLIBRA token is an internal change in AccountDB. Users can transfer pLIBRA freely like any ERC-20 token. The transfer happens inside the pLIBRA contract and only the owner can access the transaction information.
    \item \textbf{Query}. Users can query the balance and the transaction history of his account. The query operation is a read of Chainview and thus it's not needed to interact with the blockchain.
\end{icompact}


\documentclass[10pt]{report}

\usepackage{geometry}
\geometry{
	a4paper,
	margin=1in,
	footskip=0.25in
}

\usepackage{enumerate} % for enumerate counter
\usepackage{subcaption} % for subfigures
\usepackage{amsthm} % for QED
\usepackage{mathtools} % for delimiter

\usepackage{listings} % for code
\lstset{
	language=R,
	basicstyle=\footnotesize\ttfamily,
	numbers=none,
	stepnumber=1,
	numbersep=8pt,
	showspaces=false,
	showstringspaces=false,
	showtabs=false,
	frame=single,
	tabsize=2,
	captionpos=t,
	breaklines=true,
	breakatwhitespace=false
}

\usepackage{float} % for figure [H]
\usepackage{booktabs} % for tabular
\usepackage{caption} % for \caption*
\usepackage[export]{adjustbox} % for valign=t
\usepackage{array} % for column type m
\usepackage{verbatim}
\usepackage{graphicx}
%\graphicspath{ {imgs/} }

\usepackage{fancyhdr}
\pagestyle{fancy}
\fancyhead[L]{\hwAuther}
\fancyhead[C]{\courseNo}
\fancyhead[R]{\hwNo}

\usepackage{amssymb}
\usepackage{amsmath}

%Cover
\newcommand{\courseTitle}{Introduction to Mathematical Modeling}
\newcommand{\courseNo}{Math 380}
\newcommand{\hwAuther}{Zhihao Ai}

\newcommand{\hwNo}{HW \#3}
\newcommand{\hwDate}{Due on 02/13}

\title{
	\courseTitle\\
	\hwNo\\
	\hwDate
}
\author{\hwAuther}
\date{}
%

%Custom
%\everymath{\displaystyle}
\setlength\parindent{0pt}

%Custom commands
\newcommand{\ds}{\displaystyle}
\newcommand{\ts}{\textstyle}

\newcolumntype{N}{>$ c <$}
\newcolumntype{M}[1]{>{\centering\arraybackslash $}m{#1}<{$}}

\newcommand{\abs}[1] {\left| #1 \right|}

\DeclarePairedDelimiter\autoparen{(}{)}
\newcommand{\pa}[1]{\autoparen*{#1}}

\newcommand{\var} {\text{var}}

\newcommand{\m}[1] {\mathbf{#1}}

\begin{document}

\maketitle

\section*{Section 3.1}
\begin{enumerate}
	\item [5.]
	The following data represent the growth of a population of fruit flies over a 6-week period. Test the following models by plotting an appropriate set of data. Estimate the parameters of the following models.
	\begin{table}[H]
		\centering
		\begin{tabular}{*{7}{c}}
			\toprule
			$t$ (days) & 7 & 14 & 21 & 28 & 35 & 42 \\ \midrule
			$P$ (number of observed flies) & 8 & 41 & 133 & 250 & 280 & 297 \\
			\bottomrule
		\end{tabular}
	\end{table}
	\begin{enumerate}[a.]
		\item
		$P = c_1 t$

		Plotting $P$ against $t$, we have
		\begin{figure}[H]
			\centering
			\includegraphics[width=0.4\linewidth]{s3_1/5a.png}
		\end{figure}
		$c_1$ is estimated to be $\frac{133-8}{21-7} = 8.93$.

		\item
		$P = a e^{bt}$

		Plotting $\ln{P}$ against $t$, we have
		\begin{figure}[H]
			\centering
			\begin{subfigure}[b]{.4\linewidth}
				\caption{$\ln{P}$ vs $t$}
				\includegraphics[width=\linewidth]{s3_1/5b.png}
			\end{subfigure}%%
			\begin{subfigure}[b]{.4\linewidth}
				\caption{Fitted model}
				\includegraphics[width=\linewidth]{s3_1/5bo.png}
			\end{subfigure}
		\end{figure}
		Since $\ln{P} = \ln{a} + bt$, $\ln{a}$ is estimated to be 2.7 so $a$ is about 14.88 and $b$ is estimated to be 0.1. This model is not a good fit when plotting $ a e^{bt}$ against $t$.
	\end{enumerate}

	\item [7.]
	In 1601 the German astronomer Johannes Kepler became director of the Prague Observatory. Kepler had been helping Tycho Brahe in collecting 13 years of ovservations on the relative motion of the planet Mars. By 1609 Kepler had formulated his first two laws. Kepler spent many years verifying these laws and formulating a third law, which relates the planets' orbital periods and mean distances from the sun.
	\begin{enumerate}[a.]
		\item
		Plot the period time $T$ versus the mean distance $r$ using the observational data.
		\begin{figure}[H]
			\centering
			\includegraphics[width=0.4\linewidth]{s3_1/7a.png}
		\end{figure}

		\item
		Assuming a relationship of the form
		\[
		T = C r^a
		\]
		determine the parameters $C$ and $a$ by plotting $\ln{T}$ versus $\ln{r}$. Does the model seem reasonable? Try to formulate Kepler's third law.
		\begin{figure}[H]
			\centering
			\includegraphics[width=0.4\linewidth]{s3_1/7b.png}
		\end{figure}
		Since $\ln{T} = \ln{C} + a \ln{r}$, $\ln{C}$ is estimated to be $-1.62$ so $C$ is about 0.2 and $a$ is estimated to be 1.5. Kepler's third law would be the planets' orbital periods are proportional to the mean distances from the sun to the power 1.5, or mathematically, $T = 0.2 r^{1.5}$.
	\end{enumerate}
\end{enumerate}

\section*{Section 3.2}
\begin{enumerate}
	\item [2b.]
	Formulate the mathematical model that minimizes the largest deviation between the data and the line $y=ax+b$. Solve for the estimates of $a$ and $b$.
	\begin{table}[H]
		\centering
		\begin{tabular}{*{9}{c}}
			\toprule
			$x$ & 29.1 & 48.2 & 72.7 & 92.9 & 118 & 140 & 165 & 199\\ \midrule
			$y$ & 0.0493 & 0.0821 & 0.123 & 0.154 & 0.197 & 0.234 & 0.274 & 0.328 \\
			\bottomrule
		\end{tabular}
	\end{table}
	If $r$ represents the largest absolute value of the residuals, the problem is to
	\[
	\text{Minimize } r
	\]
	subject to
	\begin{align*}
		r - (29.1a + b - 0.0493) &\ge 0\\
		r + (29.1a + b - 0.0493) &\ge 0\\
		r - (48.2 a + b - 0.0821) &\ge 0\\
		r + (48.2 a + b - 0.0821) &\ge 0\\
		r - (72.7 a + b - 0.123) &\ge 0\\
		r + (72.7 a + b - 0.123) &\ge 0\\
		r - (92.9 a + b - 0.154) &\ge 0\\
		r + (92.9 a + b - 0.154) &\ge 0\\
		r - (118 a + b - 0.197) &\ge 0\\
		r + (118 a + b - 0.197) &\ge 0\\
		r - (140 a + b - 0.234) &\ge 0\\
		r + (140 a + b - 0.234) &\ge 0\\
		r - (165 a + b - 0.274) &\ge 0\\
		r + (165 a + b - 0.274) &\ge 0 \\
		r - (199 a + b - 0.328) &\ge 0 \\
		r + (199 a + b - 0.328) &\ge 0
	\end{align*}
	Using Mathematica, $r$ is minimized when $a=0.00164038$ and $b=0.00295615$.

	\item [3.]
	For the following data, formulate the mathematical model that minimizes the largest deviation between the data and the model $y = c_1 x^2 + c_2 x + c_3$. Solve for the estimates of $c_1$, $c_2$ and $c_3$.
	\begin{table}[H]
		\centering
		\begin{tabular}{*{6}{c}}
			\toprule
			$x$ & 0.1 & 0.2 & 0.3 & 0.4 & 0.5 \\ \midrule
			$y$ & 0.06 & 0.12 & 0.36 & 0.65 & 0.95 \\
			\bottomrule
		\end{tabular}
	\end{table}
	If $r$ represents the largest absolute value of the residuals, the problem is to
	\[
	\text{Minimize } r
	\]
	subject to
	\begin{align*}
	r - (0.1^2 c_1 + 0.1 c_2 + c_3 - 0.06) &\ge 0\\
	r + (0.1^2 c_1 + 0.1 c_2 + c_3 - 0.06) &\ge 0\\
	r - (0.2^2 c_1 + 0.2 c_2 + c_3 - 0.12) &\ge 0\\
	r + (0.2^2 c_1 + 0.2 c_2 + c_3 - 0.12) &\ge 0\\
	r - (0.3^2 c_1 + 0.3 c_2 + c_3 - 0.36) &\ge 0\\
	r + (0.3^2 c_1 + 0.3 c_2 + c_3 - 0.36) &\ge 0\\
	r - (0.4^2 c_1 + 0.4 c_2 + c_3 - 0.65) &\ge 0\\
	r + (0.4^2 c_1 + 0.4 c_2 + c_3 - 0.65) &\ge 0\\
	r - (0.5^2 c_1 + 0.5 c_2 + c_3 - 0.95) &\ge 0\\
	r + (0.5^2 c_1 + 0.5 c_2 + c_3 - 0.95) &\ge 0
	\end{align*}
	Using Mathematica, $r$ is minimized when $c_1=4$, $c_2=-0.0333$ and $c_3=-0.005$.
\end{enumerate}

\end{document}


\chapter{Performance evaluation}

\section{Evaluation metrics}

The system is evaluated by checking how many landmarks are explored as time passes. A simulation is concluded when time reaches a maximum allowed value (3000). For example, if we have the following values:

\begin{center}
[100, 400, 800, 3000]
\end{center}

\noindent
The first landmark has been explored at time 100, etc. The last one has not been explored during the simulation, and so its value is set to 3000. This way, we can model the trend of the system using a time series where each time t is associated to the number of landmarks that had already been explored in such time.

\noindent
Figure \ref{fig:ts} reports a clarifier example of a time series.

\begin{figure}[H]
\centering
\includegraphics[width=8cm, keepaspectratio]{images/ts.png}
\caption{\textit{Example time series with exploration times [500, 1500, 2000, 2300].}}
\label{fig:ts}
\end{figure}

\smallskip
Moreover, we define a measure of performance (\textit{goodness}) to estimate how well the system behaves so that we can compare different combinations of parameters in a quantitative way. To do this, we consider the area under the time series (i.e., the integral of the function). Such area can assume values in range [0; 12000] (0 if no landmark has been explored during the simulation, 12000 is a theoretical max value given by $simulation\_length * n\_landmarks$). The main idea is that the greater the area, the sooner landmarks had been explored, and so higher values of goodness are preferred. Notice that, each value is then normalized in [0;1] for convenience.

\noindent
Figure \ref{fig:auc} reports a clarifier example of lower and upper bounds.

\begin{figure}[H]
\centering
\includegraphics[width=8cm, keepaspectratio]{images/auc.png}
\caption{\textit{Example time series with exploration times [500, 1000, 1300, 3000] (green). Upper and lower bounds in orange and blue respectively. The integral of the blue function is simply 0, while the one of the orange is given by 3000 * 4.}}
\label{fig:auc}
\end{figure}

\noindent
\textit{Note:} Notice that, in order to compare solutions with different expected cluster size, such measure should be refined  since the latter parameter influences the exploration times in a non negligible manner. To overcome such issue, a penalty factor may be added to cluster with lower sizes.

\section{Parameters definition}

When executing performance evaluation stage, we choose just a subset of parameters and configurations the system can be tuned upon since the total number of combination is exponential, and so it would require too much time to explore them all using a grid search technique. In particular, the following aspects are the one considered as constants:

\begin{itemize}

  \item Size of the arena: it is assumed to use a 4x4 meters arena.
  \item Position of the base: it is assumed to locate the base in the center of the arena.
  \item Few controller parameters: all non-deterministic transition parameters, gain factor in motor schema modules etc.
  \item Type of exploration: it may be interesting to test the system using different exploration strategies aside from the ballistic motion.
  \item Number of landmarks: it is assumed to have four landmarks

\end{itemize}

\noindent
The system is evaluated by changing the following parameters:

\begin{itemize}

  \item Number of employed robots: 20, 30, 40.
  \item Expected cluster size: 1, 3, 5.
  \item Number of obstacles scattered around the arena: 0, 10, 20
  \item Position of the landmarks

\end{itemize}

The first analyzed setup of the arena is reported in figure \ref{fig:arena}. The four landmarks are all placed on a same side of the arena and they are aligned so that a straight line parallel to one edge of the arena is created. Then, aside from this basic arena configuration, further evaluations will be made using different deployments of the landmarks (at the four cardinal points, at the four corners, random distribution etc.).

\begin{figure}[H]
\centering
\includegraphics[width=\linewidth]{images/arena.png}
\caption{\textit{Setup of the arena with the four landmarks located on a straight line parallel to one edge of the arena.}}
\label{fig:arena}
\end{figure}

\section{Basic arena}

When considering the basic setup of the arena, table \ref{tab:perf-table} reports the \textit{minimum guaranteed level of service} (i.e. worst observed values) upon 5 runs and the relative goodness of each casuistry. Figure \ref{fig:ts-all} shows the comparison of the cases reported in table \ref{tab:perf-table}.

\bigskip
\noindent
\textbf{Number of robots}

An increase in the number of robots improves the overall performance values in general.
Indeed, we can notice that the system can not reach the goal using cluster size three just when using twenty robots. Moreover, we obtain the best results when using the maximum number of robots (forty).
However, when dealing with an higher number of robots than forty and if keeping the same size of the arena, they may disturb each other, and so further evaluations should be made and no general rule can be inferred.

Besides, notice that the minimum guaranteed level of service can be tricky. Indeed, by looking to raw performance data (available in attached files), it is confirmed that better average performance values are obtained as the number of robot increases, despite, in some cases, a same minimum guaranteed level of service.

\bigskip
\noindent
\textbf{Cluster size}

As expected, exploration times increase proportionally to the cluster size. Indeed, aside from the trivial fact that more robots should gather, it is seen that the gathering operation itself is harder because of spatial constraints (harder for a robots to get close to a landmark if few robots are already there).

\noindent
An expected size greater than three makes the creation of a cluster harder, and often few landmarks remain unexplored at the ending of the simulation. As observed from empirical tests, such issue is mainly due to spatial problems constraints (difficulty to actually aggregate since there is not enough space). A greater time limit has been probed, and it emerged to be that clusters will be created anyway eventually. Moreover, few tests have been executed on wider arenas (e.g. 6x6, 8x8 meters) and, despite higher times due to the greater distances to travel, cluster creation resulted to be simplified.

\bigskip
\noindent
\textbf{Number of obstacles}

The insertion of obstacles is a key factor since it emerges a great difference among the study cases. Indeed, the performance will decrease independently from the adopted cluster size, and this is quite obvious since the boxes make exploration and aggregation harder (in some observed cases even impossible by leaving not enough empty space to create a proper cluster). However, notice that the gap between thirty and forty robots is filled up when using cluster size three or greater (rather, slightly better performance using thirty robots, 40 robots + 20 obstacle + 4 landmarks may create too harsh conditions for the navigation).

\bigskip
\noindent
\textbf{Miscellaneous}

\begin{itemize}

  \item As expected, the landmarks on the sides are often the last to be explored because their harder to reach (and it is harder to create cluster around them too).

\end{itemize}

\begin{table}[H]
\centering
\begin{tabular}{| c c c | c c c c | c |}

\hline
Robots & Cluster size & Obstacles & \multicolumn{4}{ c |}{Time} & Goodness \\
\hline
20 & 1 & 0  & 161& 258& 343& 1081 & 0.84 \\
20 & 1 & 10 & 300& 329& 1705& 1931& 0.64\\
20 & 1 & 20 & 266& 370& 863& 2771& 0.64\\
20 & 3 & 0  & 559& 1231& 2730& 3000& 0.37\\
20 & 3 & 10 & 3000& 3000& 3000& 3000& 0.0\\
20 & 3 & 20 & 3000& 3000& 3000& 3000& 0.0\\
20 & 5 & 0  & 3000& 3000& 3000& 3000& 0.0\\
20 & 5 & 10 & 3000& 3000& 3000& 3000& 0.0\\
20 & 5 & 20 & 3000& 3000& 3000& 3000& 0.0\\
\hline
30 & 1 & 0  & 115& 372& 414& 1032& 0.83\\
30 & 1 & 10 & 234& 418& 548& 2112& 0.72\\
30 & 1 & 20 & 317& 623& 994& 3000& 0.58\\
30 & 3 & 0  & 869& 1165& 2401& 3000& 0.33\\
30 & 3 & 10 & 1449& 1962& 2981& 3000& 0.21\\
30 & 3 & 20 & 1461& 2667& 2990& 3000& 0.15\\
30 & 5 & 0  & 3000& 3000& 3000& 3000& 0.0\\
30 & 5 & 10 & 3000& 3000& 3000& 3000& 0.0\\
30 & 5 & 20 & 3000& 3000& 3000& 3000& 0.0\\
\hline
40 & 1 & 0  & 175& 236& 367& 862& 0.86\\
40 & 1 & 10 & 268& 410& 420& 1022& 0.82\\
40 & 1 & 20 & 307& 580& 1018& 2069& 0.66\\
40 & 3 & 0  & 833& 834& 970& 2566& 0.53\\
40 & 3 & 10 & 1542& 1633& 2394& 2453& 0.33\\
40 & 3 & 20 & 1534& 2815& 3000& 3000& 0.13\\
40 & 5 & 0  & 3000& 3000& 3000& 3000& 0.0\\
40 & 5 & 10 & 3000& 3000& 3000& 3000& 0.0\\
40 & 5 & 20 & 3000& 3000& 3000& 3000& 0.0\\
\hline

\end{tabular}
\caption{\label{tab:perf-table}\textit{Evaluation of the system on 27 proposed combinations. For each casuistry, it is reported the moment of exploration of each landmark. Every value is the worst value among the registered ones. Moreover, the goodness of each combination is reported too.}}
\end{table}

\begin{figure}[H]
\centering
\includegraphics[width=\linewidth]{images/ts_all.png}
\caption{\textit{Performance on each casuistry using cluster size one and three for minimum guaranteed level of service (cluster size five is omitted since its values would always have been zero.}}
\label{fig:ts-all}
\end{figure}

\section{Further case studies}

Now, the system is probed using a different positioning of the landmarks in order to check its robustness on different cases. In particular, while fixing the cluster size to three and the number of obstacle to ten, the system is evaluated by choosing random locations for the landmarks. Configurations are dropped when the landmarks are spawned in the base or at least two of them are too close (because of possible interferences when counting neighbors through the range and bearing system).

\noindent
Table \ref{tab:perf-table-random} reports the observed results. As we can notice, the positioning of the landmarks is a key factor since it greatly influences the results. Indeed, the goodness assumes very high/low values depending on very lucky/unlucky configurations, and so the variance between the exploration times is higher than the one observed when just using the basic arena.

\noindent
Moreover, as expected, the system behaves better when employing the maximum number of robots (forty).

\bigskip
When comparing such results to the ones obtained on the basic arena (figure \ref{fig:ts-random}), it emerges that better results are generally obtained on the random ones: this is probably due to the fact that, since in the basic arena all landmarks are placed on the same side, robots that start exploring the opposite part will not find any landmark for a while, and so they are vain for the first part of the simulation. Obviously, such considerations can not be made for random deployment of the landmarks in general, and so better performance are obtained since all robots take part in the creation of the clusters. In the end, notice that the clustering behavior emerges independently from the number of robots when using random arenas, while it is not true when using twenty robots on the basic arena (at least in the specified time boundaries).

\bigskip
\noindent
\textit{Note:} Such evaluations may be tricky (or even misleading) since more attempts on further cases should be made in order to apply any statical technique to validate the results.

\begin{table}[H]
\centering
\begin{tabular}{| c c c | c c c c | c |}

\hline
Robots & Cluster size & Obstacles & \multicolumn{4}{ c |}{Time} & Goodness \\
\hline

\multirow{5}{4em}{20} & \multirow{5}{4em}{3} & \multirow{5}{4em}{10} & 231& 886& 2388& 3000& 0.45\\
& & & 396& 640& 3000& 3000 & 0.41\\
& & & 112& 975& 2645& 2871 & 0.45\\
& & & 454& 1112& 1921& 2678 & 0.48\\
& & & 432& 1001& 2319& 2992 & 0.43\\
\hline

\multirow{5}{4em}{30} & \multirow{5}{4em}{3} & \multirow{5}{4em}{10} & 325& 344& 1481& 1684& 0.68\\
& & & 101& 863& 907& 3000& 0.59\\
& & & 494& 653& 3000& 3000& 0.40\\
& & & 575& 1166& 3000& 3000& 0.35\\
& & & 1310& 1667& 1718& 3000& 0.40\\
\hline

\multirow{5}{4em}{40} & \multirow{5}{4em}{3} & \multirow{5}{4em}{10} & 524& 800& 815& 1060& 0.73\\
& & & 183& 942& 2445& 2771& 0.47\\
& & & 529& 854& 1926& 2714& 0.49\\
& & & 960& 1278& 2167& 3000& 0.38\\
& & & 102& 672& 719& 3000& 0.62\\
\hline

\end{tabular}
\caption{\label{tab:perf-table-random}\textit{Evaluation of the system using random positioning of the landmarks. For each casuistry, it is reported the moment of exploration of each landmark for five random setups of the landmarks. Moreover, the goodness of each combination is reported too.}}
\end{table}

\begin{figure}[H]
\centering
\includegraphics[width=\linewidth]{images/ts_random.png}
\caption{\textit{Comparison of the performance obtained on basic arena and on random ones.}}
\label{fig:ts-random}
\end{figure}


\subsection{Comparision with Ethereum Distributed Key Generation Paper}
\label{ssec:ethdkg_comparison}

In~\cite{ethdkg}, the authors presented the Ethereum
Distributed Key Generation whitepaper.
Here, participants work together to form a master public key
(the public key for the group)
based on verifiable secret sharing.
The master secret key (the private key for the group)
is the summation of the shared secrets correctly shared by
valiadators.
This system may proceed even with a limited number of Byzantine actors.
In the end, participants may compute partial signatures of a message
which may be combined to form a valid group signature.

While we follow the procedure of~\cite{ethdkg} in general,
there are other concerns that must be taken into consideration.
The MadNetwork will be a sidechain of Ethereum,
and the keys we construct will be used to sign the blocks of our sidechain.
By anchoring into Ethereum, we are able to use smart contracts to enforce
compliance with the consensus algorithm as well as punish
those who behave in a cryptographically-verifiable malicious way.
Malicious behavior include submitting false keys, submitting
false proofs, signing invalid messages, and similar actions.
This is different from the original paper where everything
happened on Ethereum and participants who
acted maliciously during the key derivation stage would still
be allowed to proceed because honest actors would be able to
work together to derive the correct information.
In that setting, the focus was having a $\parens{t,n}$-thresholded
system whereby $t+1$ actors are required to work together to
sign messages for the group.
Here, $t$ and $n$ are preassigned.
In our case, we specifically desire a Byzantine-fault tolerant
thresholded system, whereby we require $t = \ceil{2n/3}-1$.
Even though we have the same $t$ values for $n = 3k$ and $n = 3k-1$
(thereby potentially allowing one malicious validator to be
ejected without forcing a required restart),
we will restart the DKG process whenever malicious behavior
is cryptographically proven.
By forcing a restart upon pernicious action,
validators are discouraged from malicious activity as well
as lose the opportunity to earn block rewards.
We also restart when validators fail to submit the required
information.
In this case when malicious intent cannot be proven due to
the possiblity of technical failure, a minor fine will be
given due to time cost of the other participants.

During the DKG process, all of the material necessary
to recover a participant's secret is available provided
enough actors work together.
As mentioned in~\cite{ethdkg}, this is useful in order to allow
for the DKG to continue even if certain participant's fail to cooperate,
but the problem is that with this secret information it would
be possible for a large enough malicious subset (specifically,
a majority greater than two-thirds) to recover a secret
and produce valid signatures from participant $P_{i}$
proving malicious behavior that is not, in fact, perpetrated by $P_{i}$.
This is of serious concern because participants
stake tokens on the basis of being validators
on our blockchain and receiving block rewards for their computation
and are threatened with losing stake should they
behave nefariously.

Requiring at least 67\% percent of the validators to work together
in order to produce stake-burning results is
better than a 51\% Attack which can occur
in Proof-of-Work blockchains but it leaves something to be desired;
we would like for honest validators to be immune to
the previously-mentioned behavior even if there is only
one honest participant.
To combat this, we will require all messages to be signed
by a participant's Ethereum's private key.
This will allow all messages to be validated against the Ethereum
public key and will be safe so long as the Ethereum private key
is secure.
In this way, any secret information leaked during the distributed
key generation will not enable Byzantine actors to produce
cryptographic proof of malicious behavior against honest participants.


\subsection{Estimating the population variance}


\subsection{Proper Motions}

\textbf{key}: \texttt{/proper\_motion}

\subsubsection{Datasets}

\begin{center}
\begin{table}[H]
\begin{tabular}{ | c | c | c | c | }
    \hline
    Variable & Dataset Name & Supplementary Datasets &  attributes \\
    \hline\hline
    Radial distance & \texttt{r\(^*\)} & \texttt{\(\Delta\)r} & \texttt{unit} \\
    \hline
    Total proper motion & \texttt{PM\_tot\(^*\)} &
    \texttt{\(\Delta\)PM\_tot\(^*\)} & \texttt{unit}\\
    \hline
    Proper motion ratio & \texttt{PM\_ratio\(^*\)} &
    \texttt{\(\Delta\)PM\_ratio\(^*\)} & \texttt{method} \\
    \hline
    Radial proper motion & \texttt{PM\_R\(^*\)} &
    \texttt{\(\Delta\)PM\_R\(^*\)} & \texttt{unit}\\
    \hline
    Tangential proper motion & \texttt{PM\_T\(^*\)} &
    \texttt{\(\Delta\)PM\_T\(^*\)} & \texttt{unit}\\
    \hline
\end{tabular}
\caption*{
    The proper motions can be fit on any of these components, alone or as a
    group. The corresponding errors are required for any.
}
\end{table}
\end{center}

\subsubsection{Attributes}

\begin{center}
\begin{table}[H]
\begin{tabular}{ | c | c | }
    \hline
    Attribute & Description \\
    \hline\hline
    \texttt{source} & Literature source(s) of data \\
    \hline
    \texttt{m} & Mean stellar mass of tracer stars [\(M_\odot\)] \\
    \hline
\end{tabular}
\end{table}
\end{center}


\documentclass[aps,notitlepage,nofootinbib,11pt]{revtex4-1}

% linking references
\usepackage{hyperref}
\hypersetup{
  breaklinks=true,
  colorlinks=true,
  linkcolor=blue,
  filecolor=magenta,
  urlcolor=cyan,
}

%%% symbols, notations, etc.
\usepackage{physics,braket,bm,commath,amssymb} % physics and math
\renewcommand{\t}{\text} % text in math mode
\newcommand{\f}[2]{\dfrac{#1}{#2}} % shorthand for fractions
\newcommand{\p}[1]{\left(#1\right)} % parenthesis
\renewcommand{\sp}[1]{\left[#1\right]} % square parenthesis
\renewcommand{\set}[1]{\left\{#1\right\}} % curly parenthesis
\renewcommand{\v}{\bm} % bold vectors
\newcommand{\uv}[1]{\hat{\v{#1}}} % unit vectors
\renewcommand{\d}{\partial} % partial d
\renewcommand{\c}{\cdot} % inner product
\newcommand{\bk}{\Braket} % shorthand for braket notation

\usepackage[inline]{enumitem} % for inline enumeration

% leave a note in the text, visible in the compiled document
\newcommand{\note}[1]{\textcolor{red}{#1}}
\usepackage{ulem} % for strikeout text

\usepackage{dsfont}
\newcommand{\1}{\mathds{1}}

\newcommand{\up}{\uparrow}
\newcommand{\dn}{\downarrow}
\newcommand{\E}{\mathcal{E}}
\renewcommand{\H}{\mathcal{H}}
\newcommand{\K}{\mathcal{K}}
\newcommand{\Z}{\mathbb{Z}}

\usepackage{accents}
\newcommand{\utilde}[1]{\underaccent{\tilde}{#1}}

\newcommand{\g}{\text{g}}
\newcommand{\e}{\text{e}}

\begin{document}

\title{Interactions in the 1-D optical lattice clock}

\author{Michael A. Perlin}

\maketitle

The interaction Hamiltonian for nuclear-spin polarized fermionic
alkali-earth(-like) atoms is
\begin{align}
  H_{\t{int}} = G \int d^3x~
  \psi_\e^\dag\p{x} \psi_\g^\dag\p{x} \psi_\g\p{x} \psi_\e\p{x},
  &&
  G \equiv \f{4\pi a_{\e\g^-}}{m_A},
\end{align}
where $\psi_\sigma$ is a fermionic field operator for atoms in
electronic state $s\in\set{\g,\e}$, $a_{eg}^-$ is a scattering length,
and $m_A$ is the mass of a single atom.  On a 1-D lattice with tight
transverse confinement, we can expand the field operators as
\begin{align}
  \psi_\sigma\p{x} = \sum_{q,n} \phi_{qn}\p{x} c_{qn\sigma},
\end{align}
for wavefunctions $\phi_{qn}$ and annihilation operators
$c_{qn\sigma}$ additionally indexed by quasi-momenta $q$ and band
indices $n$.  The interaction Hamiltonian then becomes
\begin{align}
  H_{\t{int}} = G \sum K^{pk;q\ell}_{rm;sn}
  c_{rm,\e}^\dag c_{sn,\g}^\dag c_{q\ell,\g} c_{pk,\e},
  &&
  K^{pk;q\ell}_{rm;sn} \equiv \int d^3x~
  \phi_{rm}\p{x}^* \phi_{sn}\p{x}^* \phi_{q\ell}\p{x} \phi_{pk}\p{x}.
\end{align}
By conservation of momentum, we know that $K^{pk;q\ell}_{rm;sn}=0$
unless $p+q+r+s=0$ (where we note that all quasi-momenta are defined
modulo 2 in units of the lattice wavenumber), so we can write
\begin{align}
  H_{\t{int}} = G \sum K^{pk;q\ell}_{p+r,m;q-r,n}
  c_{p+r,m,\e}^\dag c_{q-r,n,\g}^\dag c_{q\ell,\g} c_{pk,\e}
  \approx G \sum K^{k\ell}_{mn}
  c_{p+r,m,\e}^\dag c_{q-r,n,\g}^\dag c_{q\ell,\g} c_{pk,\e},
  \label{eq:H_int_full}
\end{align}
where we made the approximation that $K^{pk;q\ell}_{p+r,m;q-r,n}$ only
weakly depends on the quasi-momenta $\p{p,q,r}$.  We note that for the
cases we will be considering, this approximation breaks down at the
$\sim10\%$ level for lattices with depth $\lesssim 15 E_R$, where
$E_R$ is the lattice recoil energy.

\section{Single-band spin model}

We now restrict ourselves to considering only atoms a single band,
such that $K^{k\ell}_{mn}\to K$ and the single-particle energy (up to
a global shift) takes the form $E_q=-2J\cos\p{\pi q}$, where we measure
momenta $q$ in units of the lattice wavenumber.  If
$\abs{J}\gg\abs{GK}$, then by the secular approximation we can neglect
terms in $H_{\t{int}}$ which do not conserve the sum of
single-particle energies.  By solving the single-particle energy
conservation condition, one can find that this approximation amounts
to neglecting terms with $\set{p,q}\ne\set{p+r,q-r}$; that is, atoms
in different clock states can only interact via
\begin{enumerate*}[label=(\roman*)]
\item direct density-density terms, and
\item terms which exchange their momenta.
\end{enumerate*}
The surviving terms in \eqref{eq:H_int_full} are thus
\begin{align}
  H_{\t{int}}^{\t{single-band}}
  = G K \sum \p{c_{p,\e}^\dag c_{q,\g}^\dag c_{q,\g} c_{p,\e}
    + c_{q,\e}^\dag c_{p,\g}^\dag c_{q,\g} c_{p,\e}}
  = G K \sum \p{n_{q,\g} n_{p,\e}
    - c_{q,\e}^\dag c_{q,\g} c_{p,\g}^\dag c_{p,\e}}.
\end{align}
Defining
\begin{align}
  \1_p \equiv c_{p,\e}^\dag c_{p,\e} + c_{p,\g}^\dag c_{p,\g},
  &&
  \sigma_p^j \equiv \sum_{\alpha,\beta}
  c_{p\alpha}^\dag \sigma^j_{\alpha\beta} c_{p\beta},
\end{align}
for Pauli matrices $\sigma^j$, we can therefore write
\begin{align}
  H_{\t{int}}^{\t{single-band}} = G K \sum
  \sp{\p{\f{\1_q+\sigma_q^z}{2}} \p{\f{\1_p-\sigma_p^z}{2}}
    - \sigma_q^- \sigma_p^+}.
\end{align}
Up to a global shift in energy, this result is equivalently
\begin{align}
  H_{\t{int}}^{\t{single-band}}
  = - \f14 G K \sum \v\sigma_q\c\v\sigma_p
  = - G K \v S \c \v S,
  &&
  \v S \equiv \f12 \sum_p \v\sigma_p.
\end{align}
Note that the collective spin operators $\v S$ are extensive in the
number of particles, $N$, and that the overlap integral $K\sim L^{-1}$
for $L$ lattice sites, as
\begin{align}
  K = \int d^3x \abs{\phi_0\p{x}}^4
  = \int d^3x \abs{\f1{\sqrt{L}}\sum_j w_j\p{x}}^4
  \approx \f1{L^2} \sum_j \int d^3x \abs{w_j\p{x}}^4
  = \f1L \int d^3x \abs{w_0\p{x}}^4,
\end{align}
where $w_j\p{x}$ is a ground-band Wannier orbital localized at site
$j$, and the remaining overlap integral is independent of $L$.  The
approximation above is equivalent to neglecting inter-site
interactions and interaction-assisted hopping.  If $L\sim N$ then the
single-band interaction Hamiltonian is extensive in the number of
particles ($N$), as one should expect.

\section{Inter-band interactions}

We now consider interactions between atoms in two different bands, and
define $a_{p\sigma} \equiv c_{p,0,\sigma}$ (for atoms in band 0) and
$b_{p\sigma} \equiv c_{p,1,\sigma}$ (for atoms in band 1).  The
single-particle energies in the first two bands take the form
$E_{qn}=\bar E_n+2J_n\cos\p{\pi q}$ with
$\abs{\bar E_1-\bar E_0}\gg\abs{J_1}\gg\abs{J_0}$.  In the weakly
interacting limit, conserving single-particle energies requires
conserving particle number within each band, so the relevant
interactions are
\begin{align}
  H_{\t{int}}^{\t{inter-band}}
  = G K_{0,1} \sum
  \p{a_{p+r,\sigma}^\dag b_{q-r,\bar\sigma}^\dag
    + b_{p+r,\sigma}^\dag a_{q-r,\bar\sigma}^\dag}
  b_{q\bar\sigma} a_{p\sigma}
\end{align}
for $K_{0,1}\equiv K^{0,1}_{0,1}=-K^{0,0}_{1,1}>0$.  In words: atoms
in different bands may either remain in their respective clock states,
or swap a clock excitation.

The band curvatures from nonzero $J_0,J_1$ further restrict allowed
momentum changes (i.e. values of $r$) from inter-band interactions by
imposing additional constraints to conserve net single-particle
energy.  In the limit $\abs{J_1}\gg\abs{J_0}$, we find that the only
terms which conserve net single-particle energy are proportional to
$b_{q\tau}^\dag b_{q\sigma}$ and $b_{-q,\tau}^\dag b_{q\sigma}$, which
gives us
\begin{multline}
  H_{\t{int}}^{\t{inter-band}}
  = G K_{0,1} \sum
  \p{a_{p\sigma}^\dag b_{q\bar\sigma}^\dag
    + b_{q\sigma}^\dag a_{p\bar\sigma}^\dag
    + a_{p+2q,\sigma}^\dag b_{-q,\bar\sigma}^\dag
    + b_{-q,\sigma}^\dag a_{p+2q,\bar\sigma}^\dag}
  b_{q\bar\sigma} a_{p\sigma} \\
  = G K_{0,1} \sum
  \p{b_{q\bar\sigma}^\dag b_{q\bar\sigma} a_{p\sigma}^\dag a_{p\sigma}
    - b_{q\sigma}^\dag b_{q\bar\sigma} a_{p\bar\sigma}^\dag a_{p\sigma}
    + b_{-q,\bar\sigma}^\dag b_{q\bar\sigma} a_{p+2q,\sigma}^\dag a_{p\sigma}
    - b_{-q,\sigma}^\dag b_{q\bar\sigma} a_{p+2q,\bar\sigma}^\dag a_{p\sigma}}.
\end{multline}
The first two terms in this sum
($\sim b_{q\bar\sigma}^\dag b_{q\bar\sigma}$ and
$b_{q\sigma}^\dag b_{q\bar\sigma}$) correspond to density-density
terms and an exchange of clock state between atoms in different bands.
Unlike the single-band case, momentum-exchanging processes are now
disallowed due to unequal band curvatures: the fact that $J_0\ne J_1$
implies $E_{p,0}+E_{q,1}\ne E_{q,0}+E_{p,1}$.  The latter terms in the
sum ($\sim b_{-q,\bar\sigma}^\dag b_{q\bar\sigma}$ and
$b_{-q,\sigma}^\dag b_{q\bar\sigma}$) appear because
$E_{q,1}=E_{-q,1}$, i.e. the excited-band atom pays no energetic
penalty for the momentum change $q\to-q$.  To conserve net momentum in
such a process, the ground-band atom must simultaneously change
momentum as $p\to p+2q$.  At face value, this process does not
conserve energy: $E_{p,0}\ne E_{p+2q,0}$, and in turn
$E_{p,0}+E_{q,1}\ne E_{p+2q,0}+E_{-q,1}$.  For this reason, such a
process was not allowed in the single-band case.  In the two-band case
with $\abs{J_1}\gg\abs{J_0}$, however, small changes in the momentum
of the excited-band atom result in large changes in its
single-particle energy (i.e. large on the scale of conserved energy
violation, which is $\sim J_0$).  A small momentum shift
$-q\to-q+\delta q$ (together with a corresponding shift
$p+2q\to p+2q-\delta q$) is therefore sufficient to restore the
initial single-particle energy of the two atoms.

We can simplify the first set of terms of the inter-band Hamiltonian
similarly to the way that we did in the single-band case by defining
collective (pseudo-)spin operators $\v S_n$ for band $n$.  Up to a
global shift in energy, we can then take
\begin{align}
  \sum \p{b_{q\bar\sigma}^\dag b_{q\bar\sigma} a_{p\sigma}^\dag a_{p\sigma}
    - b_{q\sigma}^\dag b_{q\bar\sigma} a_{p\bar\sigma}^\dag a_{p\sigma}}
  \to -2\v S_0\c\v S_1,
\end{align}
which implies
\begin{align}
  H_{\t{int}}^{\t{inter-band}}
  = -2 G K_{0,1} \v S_0\c\v S_1
  + G K_{0,1} \sum
  \p{b_{-q,\bar\sigma}^\dag b_{q\bar\sigma} a_{p+2q,\sigma}^\dag a_{p\sigma}
    - b_{-q,\sigma}^\dag b_{q\bar\sigma} a_{p+2q,\bar\sigma}^\dag a_{p\sigma}}.
\end{align}

\section{Two-atom band-hopping}

If we use driving schemes to make $\bar E_1=\bar E_0$ (discussed in a
separate set of notes), we must also consider interaction terms which
do not conserve particle number within each band.  Such terms take the
form
\begin{align}
  H_{\t{int}}^{\t{band-hopping}} = - G K_{0,1}
  \sum \p{b_{p+r,\e}^\dag b_{q-r,\g}^\dag a_{q,\g} a_{p,\e} + \t{h.c.}}.
  \label{eq:H_int_band_hopping}
\end{align}
Energy conservation in the limit $\abs{J_1}\gg\abs{J_0}$ now forces
$r=\p{q-p}/2\pm1/2$, such that the single-particle energies of
excited-band states addressed by $H_{\t{int}}^{\t{band-hopping}}$ are
\begin{multline}
  2J_1\sp{\cos\p{\pi\sp{p+r}} + \cos\p{\pi\sp{q-r}}}
  = 2J_1\sp{\cos\p{\pi~\f{p+q}{2}+\f{\pi}{2}}
    + \cos\p{\pi~\f{p+q}{2}-\f{\pi}{2}}} \\
  = 2J_1\sp{-\sin\p{\pi~\f{p+q}{2}} + \sin\p{\pi~\f{p+q}{2}}}
  = 0.
\end{multline}
Similarly to the situation we encountered in the case of inter-band
interactions, at face value a constant single-particle energy of all
excited-band states generally implies that energy is not conserved by
the band-hopping processes in \eqref{eq:H_int_band_hopping}.  Due to
the strong dependence of excited-band single-particle energies
$E_{q,1}$ on quasi-momenta $q$, however, energy conservation can be
restored by a small shift $r\to r+\delta r$.  Keeping only terms in
\eqref{eq:H_int_band_hopping} with $r=\p{q-p}/2\pm1/2$, we thus find
\begin{align}
  H_{\t{int}}^{\t{band-hopping}}
  = - \sqrt{2} G K_{0,1} \sum
  \p{d_{\p{p+q}/2}^\dag a_{q,\g} a_{p,\e} + \t{h.c.}},
\end{align}
where
\begin{align}
  d_s^\dag \equiv \f1{\sqrt2}
  \p{b_{s+1/2,\e}^\dag b_{s-1/2,\g}^\dag
    + b_{s-1/2,\e}^\dag b_{s+1/2,\g}^\dag}.
\end{align}
For $s\ne t$, these two-body excited-band operators satisfy the
commutation relations of hard-core bosons, i.e.
\begin{align}
  \sp{d_s, d_t} = \sp{d_s^\dag, d_t^\dag} = \sp{d_s, d_t^\dag} = 0,
\end{align}
\begin{align}
  \sp{d_s, d_s^\dag}
  = 1 - \f12 \p{\tilde n_{s+1/2,\e}^\dag + \tilde n_{s-1/2,\e}^\dag
    + \tilde n_{s+1/2,\g}^\dag + \tilde n_{s-1/2,\g}^\dag},
  &&
  \tilde n_{p\sigma} \equiv b_{p\sigma}^\dag b_{p\sigma}.
\end{align}

\section{Net interaction Hamiltonian}

Putting everything together and letting $G_X\equiv G K_X$, our total
interaction Hamiltonian is
\begin{align}
  H_{\t{int}}
  &= - G_0\v S_0\c\v S_0 - G_1\v S_1\c\v S_1 - 2 G_{0,1}\v S_0\c\v S_1
  \tag*{} \\ &\quad + G_{0,1} \sum
  \p{b_{-q,\bar\sigma}^\dag b_{q\bar\sigma} a_{p+2q,\sigma}^\dag a_{p\sigma}
    - b_{-q,\sigma}^\dag b_{q\bar\sigma} a_{p+2q,\bar\sigma}^\dag a_{p\sigma}}
  \tag*{} \\ &\quad - \sqrt2 G_{0,1} \sum
  \p{d_{\p{p+q}/2}^\dag a_{q,\g} a_{p,\e} + \t{h.c.}},
\end{align}
where
\begin{align}
  d_s^\dag \equiv \f1{\sqrt2}
  \p{b_{s+1/2,\e}^\dag b_{s-1/2,\g}^\dag
    + b_{s-1/2,\e}^\dag b_{s+1/2,\g}^\dag}.
\end{align}
Notes:
\begin{enumerate}[label=(\roman*)]
\item The last set of terms ($\sim d_s^\dag$ and $d_s$) appear only if
  we use driving schemes to match the mean band energies, thereby
  effectively setting $\bar E_1=\bar E_0$; these terms can be
  neglected in the absence of such driving.
\item If there is a nonzero population of atoms in the excited band,
  the terms
  $\sim b_{-q,\sigma}^\dag b_{q\bar\sigma} a_{p+2q,\bar\sigma}^\dag
  a_{p\sigma}$ will generally cause delocalization of clock
  excitations across all quasi-momenta (on a time scale
  $\sim1/G_{0,1}$ which is extensive with $L$).
\end{enumerate}

\end{document}


\documentclass{ecnreport}

\stud{Option Robotique, Control \& Robotics master}
\topic{Advanced Robot Programming}

\begin{document}

\inserttitle{Advanced Robot Programming  Labs \newline C++ Programming}

\insertsubtitle{Lab 2: Mobile robot with sensors}

\section{Content of this lab}

The goal of this lab is to read, use and build C++ classes in order to develop an elementary simulator for a ground robot.

\subsection{The simulator}

The simulator is defined by several headers and source files, as defined in \Fig{fig:dirtree}.
\begin{figure}[h]
\begin{minipage}{.25\linewidth} ~ \end{minipage}
\begin{minipage}{.5\linewidth}
 \dirtree{%
.1 lab2.
.2 CMakeLists.txt.
.2 include.
.3 envir.h.
.3 geom.h.
.3 robot.h.
.3 sensor.h.
.2 src.
.3 envir.cpp.
.3 main.cpp.
.3 robot.cpp.
}
\end{minipage}
%\begin{minipage}{.2\linewidth} ~ \end{minipage}
\caption{\label{fig:dirtree} Files used by the simulator}
\end{figure}

The main file is \texttt{main.cpp} and is compiled to an executable.\\
The files \texttt{robot.h} and \texttt{robot.cpp} define a \texttt{Robot} class and will be modified in the first lab to implement new methods that allow using the simulator.

The files \texttt{envir.h} and \texttt{envir.cpp} defines the environment in which the robot is moving. These files are not to be modified.

The file \texttt{sensor.h} defines a virtual class \texttt{Sensor} that will be used to create two sensor types: range and bearing sensors.

\subsection{If you do the lab on your own computer}

You of course have to install QtCreator and CMake:\\
\texttt{sudo apt-get install cmake qtcreator} \\

You will also have to install these Ubuntu packages that are used for the plotting of the robot trajectory:\\
\texttt{sudo apt-get install python-matplotlib}

\subsection{Expected work}

During the lab the files will be modified and others will be created.
At the end of the lab, please send by email a zip file allowing to compile and test the program.

You may answer the questions by inserting comments in the code at the corresponding lines.

\subsection{Geometry structures}

In the \texttt{geom.h} file are defined two simple geometry structures:
\begin{itemize}
 \item One for a 2D pose: \texttt{Pose} with attributes \texttt{x, y, theta}
 \item One for a 2D motion: \texttt{Twist} with attributes \texttt{vx, vy, w}
\end{itemize}Those structures have classical constructors, and also methods to express change of frames:
\begin{itemize}
 \item \texttt{Pose Pose::transformDirect(Pose \_transform)} \\returns the pose  expressed in the given transform
 \item \texttt{Pose Pose::transformInverse(Pose \_transform)}\\ returns the pose expressed in the given transform inverse
 \item \texttt{Twist Twist::transformDirect(Pose \_transform)} \\returns the twist expressed in the given transform
 \item \texttt{Twist Twist::transformInverse(Pose \_transform)}\\ returns the twist expressed in the given transform inverse
 \end{itemize}

\newpage

\begin{figure}\centering
\includegraphics[width=.3\linewidth]{environment}
\caption{\label{fig:envir} Robot in its environment}
\end{figure}

\section{Building the \texttt{Robot} class}

The default behavior is the robot following a moving target in the environment. The environment consists of 4 walls defining a 20$\times$20 m square. The target is leaving the square at some point,
and for now the robot is also leaving the square as nothing tells it that there are some walls there.

\subsection{Defined methods}

Some methods of the class are already defined:
\begin{itemize}
 \item \texttt{Robot(std::string \_name, double \_x, double \_y, double \_theta)}\\
 constructor, initialize the robot with a given name at a given $(x,y,\theta)$ position
 \item \texttt{Pose pose()} \\ returns the current pose of the robot
 \item \texttt{void moveXYT(double \_vx, double \_vy, double \_omega)}\\
 sends a $(v_x, v_y, \omega)$ velocity to the robot and updates its position
 \item \texttt{void goTo(const Pose \&\_p)}\\
 tries to have the robot reach the given Pose
\end{itemize}

\subsection{Incomplete methods}

\begin{itemize}
\medskip\item[\textbf{\underline{Q1}}]  Compile and execute the program. According to the \texttt{main.cpp} file, the robot is trying to go to the position of the target. In which files is the target motion defined?

\medskip\item[\textbf{\underline{Q2}}] Explain the signature of   \texttt{Robot::Robot}, especially the way to pass arguments.

\medskip\item[\textbf{\underline{Q3}}] In practice it is often impossible to control a ground robot by sending $(x,y,\theta)$ velocities. A classical way to control such a robot is to send a setpoint with a linear velocity $v$ and an angular velocity $\omega$, expressed in the robot frame as shown in \Fig{fig:dd}.

\begin{figure}[h!]\centering
\includegraphics[width=.3\linewidth]{wheels}
\caption{\label{fig:dd} Differential drive model}
\end{figure}

The corresponding model is quite simple:
\begin{equation*}
\left\{\begin{array}{ll}
\dot x &= v\cos \theta \\
\dot y &= v\sin \theta \\
\dot \theta &= \omega
\end{array}\right.
\end{equation*}

Implement such a function in \texttt{Robot::moveVW}. This method should compute the $(x,y,\theta)$ velocities from $(v,\omega)$ and then call the \texttt{Robot::moveXYT} method.

\medskip\item[\textbf{\underline{Q4}}] Now that a realistic way to control the robot is possible, should the \texttt{Robot::moveXYT} method stay available for external use? What can we do in the \texttt{robot.h} file to make it impossible to use it from outside the \texttt{Robot} class?

\medskip\item[\textbf{\underline{Q5}}] The \texttt{moveWithSensor} method was using the XYT motion, which is not realistic.
Modify it so that it calls the \texttt{moveVW} method. A simple way to change a desired $(\dot x, \dot y, \dot \theta)$ motion
to a $(v, \omega)$ motion is:
\begin{equation*}\left\{\begin{array}{ll}
 v& = \dot x\\
 \omega &= \alpha\dot y + \dot \theta\end{array}\right.
\end{equation*}We will use $\alpha = 20$ here.

\medskip\item[\textbf{\underline{Q5}}] When a robot is equipped with two actuated wheels, a simple model is the differential drive model, as shown in \Fig{fig:dd}. Assuming the two wheels have a radius $r$ and are separated with a distance $b$, then the kinematic model yields:
\begin{equation*}\label{eq:dk}
\left\{\begin{array}{ll}
v &= \displaystyle r \frac{\omega_l + \omega_r}{2} \\
\omega &= \displaystyle r \frac{\omega_l - \omega_r}{2b}
\end{array}\right.
\end{equation*}
We will need to define new attributes in the \texttt{Robot} class in order to initialize the radius and base distance.
Create also a new method in the \texttt{Robot} class, called \texttt{initWheel}, that does so. In the \texttt{main.cpp}, use the following values:
\begin{equation*}
\left\{\begin{array}{ll}
r &= 0.07 ~m \\
b &= 0.3 ~m
\end{array}\right.
\end{equation*}

\medskip\item[\textbf{\underline{Q6}}] Now that the robot has some wheel radius and inter-distance, implement the \texttt{Robot::rotateWheels} method, so that it can be possible to control the robot by sending wheel velocities.
The method should call \texttt{Robot::moveXYT} after having computed the $(x,y,\theta)$ velocities from $(\omega_l, \omega_r)$.

\medskip\item[\textbf{\underline{Q7}}] By using a \texttt{bool wheels\_init\_} attribute, make sure that it is impossible to do anything in \texttt{Robot::rotateWheels} if the radius and base have not been initialized.

\subsection{Velocity limits}

With the current simulation, we can control the robot:
\begin{itemize}
\item by sending linear and angular velocity setpoint with \texttt{Robot::moveVW}
\item or by sending wheel velocities with \texttt{Robot::motateWheels}
\end{itemize}

These two methods call \texttt{Robot::moveXYT}\footnote{which should not be calable anymore from outside the \texttt{Robot} class} and the robot can reach any velocity. In practice, the wheels have a limited velocity at $\pm$10 rad/s.

\medskip\item[\textbf{\underline{Q1}}] Modify the \texttt{Robot::initWheels} method in order to pass a new argument that defines the wheel angular velocity limit.
You may need to define a new attribute of the \texttt{Robot} class to store this limit.

\medskip\item[\textbf{\underline{Q2}}] Modify the \texttt{Robot::rotateWheels} method in order to ensure that the applied velocities $(\omega_l, \omega_r)$ are within the bounds.
The method should also print a message if the velocity setpoint is too high.
Note that if you just saturate the velocities, the robot motion will be different.
A scaling is a better strategy, in this case we keep the same ratio between $\omega_l$ and $\omega_r$ according to the following algorithm:

\def\wl{\omega_l}
\def\wr{\omega_r}
\def\wm{\omega_{\text{max}}}

\begin{algorithm}[!h]
\SetKwComment{Comment}{(}{)}
% \SetAlgoLined
\KwData {desired wheel velocities $\wl$, $\wr$, velocity limit $\wm$}
\KwResult {actual velocities $\wl$, $\wr$}
$a\gets$ max($|\wl|/\wm$,$|\wr|/\wm$)\;
\If{$a <$ 1}{$a\gets$1\;}
\Return $\wl/a$, $\wr/a$\;
\caption{Scale wheel velocities with maximum value}
\label{algo:grad}
\end{algorithm}

\medskip\item[\textbf{\underline{Q3}}] Although the robot actually moves by having its wheels rotate,
it is more natural to send linear and angular velocity setpoints. Modify the
\texttt{Robot::moveVW} method so that a $(v,\omega)$ setpoint is changed to a $(\omega_l,\omega_r)$ setpoint that will then be called through \texttt{Robot::rotateWheels}.
 The inverse of model \eqref{eq:dk} yields:
\begin{equation}
\left\{\begin{array}{ll}
\omega_l &= \displaystyle \frac{v + b\omega}{r} \\
\omega_r &= \displaystyle \frac{v - b\omega}{r}
\end{array}\right.
\end{equation}
The corresponding behavior should be that the robot cannot follow perfectly the target anymore, because it is not fast enough.
\end{itemize}

% \begin{figure}[h!]
% \includegraphics[width=.4\linewidth]{xyt} \quad \includegraphics[width=.4\linewidth]{vw}
%
% \end{figure}
\newpage

\section{Sensors}

In this section we will try to avoid the walls by using some range sensors.

The \texttt{sensor.h} files defines a \texttt{Sensor} class that has the following methods:
\begin{itemize}
\item \texttt{Sensor(Robot \&\_robot, double \_x, double \_y, double \_theta)}\\initializes a sensor at a given position on the given robot
\item \texttt{virtual void update(const Pose \&\_p)}\\ updates the measurement from the sensor current position
\item \texttt{virtual void correctTwist(Twist \&\_v)}\\ checks if the given Twist is fine with the current sensor measurement
\item \texttt{void updateFromRobotPose(const Pose \&\_p)}\\ computes the sensor absolute position from the given robot pose, then calls \texttt{update}
\item \texttt{void correctRobotTwist(Twist \&\_v)}\\ computes the twist in the sensor space, then calls \texttt{correctTwist}
\end{itemize}
Some of the methods are pure virtual functions, which makes the \texttt{Sensor} class an abstract class.
It is thus impossible to declare a variable to be of \texttt{Sensor} type, as this class is only designed to build daughter-classes depending on the sensor type.

The \texttt{Robot} class already has a attribute called \texttt{sensors\_} which is a vector of \texttt{Sensor*}.

For example to update all sensors with the current robot pose, we can write the following:
\begin{cppcode}
    for(auto & sensor: sensors_)
	sensor->updateFromRobotPose(pose_);
\end{cppcode}The arrow is because we use a pointer and not an actual value. The corresponding methods have thus to be
called with an arrow instead of a dot.

\subsection{Range sensor}

\begin{itemize}
\medskip\item[\textbf{\underline{Q1}}] Create a \texttt{sensor\_range.h} file that defines a \texttt{RangeSensor} class that is derived from \texttt{Sensor}. The \texttt{update} and \texttt{correctTwist} methods have to be defined so that the code compiles. For now, just make the methods print something to the screen.
As the \texttt{Sensor} class does not have a default constructor, the \texttt{RangeSensor} class must have its constructor call directly the one from  \texttt{Sensor}:
\begin{center}\cppstyle
\begin{lstlisting}
class RangeSensor : public Sensor
{
public:
    RangeSensor(Robot &_robot, double _x, double _y, double _theta) :
	Sensor(_robot, _x,  _y,  _theta) // call the Sensor constructor
        {}	// the RangeSensor constructor does nothing more
};
\end{lstlisting}
\end{center}

\medskip\item[\textbf{\underline{Q2}}] Include this file in \texttt{main.cpp} and declare a \texttt{RangeSensor} variable.  We will use a front range sensor placed at $(0.1, 0,0)$ in the robot frame.

\medskip\item[\textbf{\underline{Q3}}] In the \texttt{Robot::moveWithSensor} method we currently do not take into account the sensor measurement.
Before calling \texttt{moveVW} we should loop through all the sensors of the robot and call their \texttt{updateFromRobotPose} method.

\medskip\item[\textbf{\underline{Q4}}] In this question we will build the \texttt{update} function of the range sensor.
This sensor should compute the distance to the nearest wall in the direction of the x-axis.\\

In the \texttt{envir\_} attribute of the sensor class, the walls are defined by a list of points available in \texttt{envir\_->walls}. \Fig{fig:dist} shows a configuration where the sensor is at $(x,y,\theta)$ and is facing a wall defined by $(x_1,y_1)$ and $(x_2,y_2)$.
\begin{figure}[h]\centering
\includegraphics[width=.3\linewidth]{sensor}
\caption{Distance to a segment defined by two points.}
\label{fig:dist}
\end{figure}
In this case, the distance to the wall is:
\begin{equation}
d = \frac{x_{1} y_{2} - x_{1} y - x_{2} y_{1} + x_{2} y + x y_{1} - x y_{2}}{x_{1} \sin\theta - x_{2} \sin\theta - y_{1} \cos\theta + y_{2} \cos\theta}
\end{equation}
The computed distance is positive if the wall is in front of the sensor, and negative if it is behind (in this case this wall is actually not measured). Also, the denominator may be null if the wall is parallel to the sensor orientation.

A simple code to loop trough all the walls is:
\begin{center}\cppstyle
\begin{lstlisting}
Pose p1, p2;
for(int i=0;i<envir_->walls.size();++i)
{
    p1 = envir_->walls[i];
    p2 = envir_->walls[(i+1)%envir_->walls.size()];

    // do whatever you want to do with points p1 and p2
}
\end{lstlisting}
\end{center}

Define the \texttt{update} function so that it updates the attribute \texttt{s\_} of the sensor with the distance to the nearest wall. Make it also print the distance to see if it is fine.

\medskip\item[\textbf{\underline{Q5}}] We now want the sensor to be able to modify the robot twist to prevent any collisions, which is the goal of the \texttt{correctTwist} method.
We assume the \texttt{Twist} that is passed to this method is already expressed in the sensor frame. Hence we are only interested in the \texttt{vx} attribute and do not want it to be too large (fast motion in the sensor axis) if we are near to a wall.\\
A simple way to do so is to define a minimum security range and to impose an upper bound to the velocity:

\medskip\item[\textbf{\underline{Q6}}] Modify the \texttt{Robot::moveWithSensor} method so that we also check the current robot twist by calling the \texttt{correctRobotTwist} method for all sensors. The robot should then stay inside the walls. We will use the following parameters:
\begin{equation*}
\left\{\begin{array}{ll}
g &= .1 \\
s_m &= 0.1~ m
\end{array}\right.
\end{equation*}

\begin{algorithm}[!h]
\SetKwComment{Comment}{(}{)}
% \SetAlgoLined
\KwData {Current twist $T$, current range $s$, gain $g$, minimum range $s_m$}
\KwResult {Modified twist $T$}
\If{$T.vx > g*(s-s_m)$}{$T.vx \gets g*(s-s_m)$\;}
\Return $T$
\caption{Modify the given twist to avoid collisions}
\label{algo:range}
\end{algorithm}
\medskip\item[\textbf{\underline{Q7}}] Add some other range sensors to the robot to check if everything is going fine.
\end{itemize}

\newpage

\subsection{Bearing sensor}

In this section we will create a new kind of sensor, that returns the bearing angle to the other robot in the simulation.
Define first a new robot with smaller wheels (0.05 m). \\
In the main loop, we just want this robot to go forward at 0.4 m/s: \\\texttt{robot2.moveWithSensor(Twist(0.4,0,0));}\\
Of course it will go out of the wall for now.

\begin{itemize}
\medskip\item[\textbf{\underline{Q1}}] Create a \texttt{sensor\_bearing.h} file that defines a \texttt{SensorBearing} class that is derived from \texttt{Sensor}. The \texttt{update} and \texttt{correctTwist} methods have to be defined so that the code compiles. For now, just make the methods print something to the screen.

\medskip\item[\textbf{\underline{Q2}}] Include this file in \texttt{main.cpp} and declare a \texttt{SensorBearing} variable.  We will use a front bearing sensor placed at $(0.1, 0,0)$ in the second robot frame.

\medskip\item[\textbf{\underline{Q3}}] Here we build the \texttt{update} method. The sensor measurement should be the angle under which the sensor is detecting another robot.
We have to loop through all the robots of the environment, which can be done with this loop:
\begin{center}\cppstyle
\begin{lstlisting}
// look for first other robot
    for(auto other: envir_->robots_)
	if(other != robot_)
	{
	    // compute angle between sensor and detected robot

	    break;
	}
    // set angle back to [-pi,pi]
\end{lstlisting}
\end{center}
The angle between the sensor and the robot can be computed with:
\begin{equation*}
 \alpha = \text{arctan2}(y_r - y_s, x_r-x_s) - \theta_s
\end{equation*}where $(x_s,y_s,\theta_s)$ is the sensor pose and $(x_r,y_r)$ is the robot position.

\medskip\item[\textbf{\underline{Q4}}] We now build the \texttt{correctTwist} method. The bearing sensor should try to align with its target. To do so, we just want to change the rotation velocity:
\begin{algorithm}[!h]
\SetKwComment{Comment}{(}{)}
% \SetAlgoLined
\KwData {Current twist $T$, current bearing $s$, gain $g$}
\KwResult {Modified twist $T$}
$T.w \gets T.w - g\times s$\;
\Return $T$
\caption{Modify the given twist to avoid collisions}
\label{algo:bearing}
\end{algorithm}

We use this method with the following parameters: $g = 0.5$.

\medskip\item[\textbf{\underline{Q5}}] Check that the second robot now follows the first robot, just by using its bearing sensor.

\end{itemize}

\end{document}


% !TEX root=../pldi2019.tex

\section{Properties}
\label{sec:properties}

% \subsection{Safety}

In order to validate our semantics, we show that our evaluation, normalisation
and handling semantics is type preserving. We additionally prove a progress
theorem for our small-step handling semantics.

Additionally, we show that the normalisation semantics is a big-step semantics.
While at first sight, this might seem obvious, the fact that we are dealing with
state complicates matters.

We show that our failing function $\Failing$ indeed only indicates expressions
that can not be normalised and that allow no further interaction.

Finally we prove that the function to compute all possible inputs $\Inputs$ is sound and complete.

\subsection{Preservation}
\label{sub:preservation}

We show that the following three preservation Theorems hold.

\begin{theorem}[Preservation under evaluation]
  % For all well typed expressions $e$ and states $s$,
  For all expressions $e$ and states $s$
  such that $\Gamma,\Sigma \infers e:\tau$ and $\Gamma,\Sigma \infers s$,
  if $e,s \evaluate e',s'$,
  then $\Gamma,\Sigma \infers e':\tau$ and $\Sigma \infers s'$.
  \label{thm:pres-eval}
\end{theorem}

Where $\Sigma \infers s$ means that for all $l\in s$, it holds that
$\Sigma(l)=\Gamma,\Sigma\infers s(l)$.

Theorem~\ref{thm:pres-eval} is shown to be correct by induction over $e$. The full
proof can be found in the appendix.

Moving on, we show that normalisation also preserves, by showing that the
following Theorem holds.

\begin{theorem}[Preservation under normalisation]
  % For all well typed expressions $e$ and states $s$,
  For all expressions $e$ and states $s$
  such that $\Gamma,\Sigma \infers e:\Task\tau$ and $\Sigma \infers s$,
  if $e,s \normalise e',s'$,
  then $\Gamma,\Sigma \infers e':\Task\tau$ and $\Sigma \infers s'$.
  \label{thm:pres-norm}
\end{theorem}

Since this semantics makes use of the value function $\Value$ and the striding semantics $\stride$. We first need to
show that preservation also holds for these two semantics.

\begin{lemma}[Task value preserves]
  % For all well typed expressions $e$ and states $s$,
  For all expressions $e$ and states $s$
  such that $\Gamma,\Sigma \infers e:\Task\tau$ and $\Sigma \infers s$,
  if $\Value{(e,s)}=v$,
  then $v:\tau$.
  \label{lem:presvalue}
\end{lemma}

\begin{lemma}[Striding preserves]
  For all expressions $e$ and states $s$
  such that $\Gamma,\Sigma \infers e:\Task\tau$ and $\Sigma \infers s$,
  if $e,s \stride e',s'$,
  then $\Gamma,\Sigma \infers e':\tau$ and $\Sigma \infers s'$.
  \label{thm:pres-stride}
\end{lemma}

Lemma~\ref{lem:presvalue} and Theorem~\ref{thm:pres-stride} are proven in the
appendix by induction over $e$. This subsequently allows us to prove
Theorem~\ref{thm:pres-norm}, again by induction over $e$.

This brings us finally to the type preservation property of the handling semantics.

\begin{theorem}[Preservation under handling]
  % For all well typed expressions $e$, states $s$, and inputs $i$,
  For all expressions $e$, states $s$ and inputs $i$
  such that $\Gamma,\Sigma \infers e:\Task\tau$ and $\Sigma \infers s$,
  if $ e,s \handle{i} e's'$,
  then $\Gamma,\Sigma\infers e':\Task\tau$ and $\Sigma\infers s'$.
  \label{thm:pres-handle}
\end{theorem}

And again, this is proven by induction over $e$.

From Theorem~\ref{thm:pres-handle} and Theorem~\ref{thm:pres-norm} we directly
obtain that the driving semantics also preserves.

\subsection{Progress}

A well-typed term of a task type is guaranteed to progress after normalisation,
unless it is failing.

We define what we mean with progress in Theorem~\ref{thm:prog-norm}.
\begin{theorem}[Progress under handling]
  For all well typed expressions $e$ and states $s$,
  % For all expressions $e$ and states $s$
  % such that $\Gamma,\Sigma \infers e:\Task\tau$ and $\Sigma \infers s$,
  if $e,s \normalise e',s'$,
  then either $\Failing(e', s')$
  or there exist $e''$, $s''$, and $i$ such that $e',s'\handle{i} e'',s''$.
  \label{thm:prog-norm}
\end{theorem}

Where a well typed espression $e$ means that $\Gamma,\Sigma\infers e:\tau$ for
some type $\tau$, and a well typed state means that $\Sigma\infers s$.

If an expression $e$ and state $s$ are well-typed, then after normalisation, it
either fails, or there exists some input $i$ that can be handled by it.
In order to prove this Theorem, we require an additional theorem.

% \paragraph{Failing}

We need to show that the failing function $\Failing$ behaves as desired.

\begin{theorem}[Failing means no interaction possible]
  For all well typed expressions $e$ and states $s$,
  % For all expressions $e$ and states $s$
  % such that $\Gamma,\Sigma \infers e:\Task\tau$ and $\Sigma \infers s$,
  and $e,s \normalise e',s'$,
  we have that $\Failing(e',s') = \True$,
  if and only if there is no input $i$
  such that $e',s'\handle{i} e'',s''$ for some $e''$ and $s''$.
  \label{thm:failing}
\end{theorem}

The Theorem above states that an expression $e$ and state $s$ are failing, if,
after normalisation, there exists no input that can be handled by it.
We prove the theorem to be true by induction on $e'$.

% \paragraph{Proof}

We now have the ingredients to prove Theorem~\ref{thm:prog-norm}.

\begin{proof}
  Given $\Gamma,\Sigma\infers e:\Task\tau$ and $\Sigma\infers s$ and after
  normalisation $e,s \normalise e',s'$, we find ourselves in either one of the
  following situations:

  There exists an $i$ such that $e',s'\handle{i} e'',s''$.

  There does not exist an $i$ such that $e',s'\handle{i} e'',s''$. In this case, we
  know that $\Failing(e',s')$ must be true, by Theorem~\ref{thm:failing}.
\end{proof}

\subsection{Soundness and Completeness of Inputs}

In order to validate the function that calculates all possible inputs $\Inputs$,
we want to show that the set of possible inputs it produces is both sound and
complete with respect to the handle semantics. By sound we mean that all inputs
in the set of possible inputs can actually be handled by the handle semantics,
and by complete we meand that the set of possible inputs contains all inputs
that can be handled by the handle semantics. Theorem~\ref{thm:safety-i} expresses
exactly this property.

\begin{theorem}[Inputs function is sound and complete]
  For all well typed expressions $e$, states $s$, and inputs $i$,
  % For all expressions $e$, states $s$, and inputs $i$
  % such that $\Gamma,\Sigma \infers e:\tau$ and $\Sigma \infers s$,
  we have that $i \in \Inputs{(e)}$ if and only if $e,s \handle{i} e',s'$.
  \label{thm:safety-i}
\end{theorem}

We prove the above theorem by induction over $e$. The proof is listed in the
appendix.


\documentclass[8pt]{article}

\usepackage{geometry}
\geometry{landscape,margin=.2in}

\usepackage[utf8]{inputenc}
\usepackage[english]{babel}

\usepackage{amsmath}
\usepackage{amssymb}

\usepackage{multicol}
\usepackage{parskip}

\DeclareMathOperator*{\argmin}{argmin}

% ------------------------------------------------------------------------
\begin{document}

% ------------------------------------------------------------------------
% Overall intro
\section*{The math of games}
All the math for playing mathmatical games, in a common place and notation.

% ------------------------------------------------------------------------
% Start the sheet...
\begin{multicols}{4}

\subsection*{Shared symbols}

\subsection*{Some formality}

% ------------------------------------------------------------------------
\section*{Others}
\subsection*{Ficticious play}
Tabulate your opponents moves, and make your next move based on those counts.

TODO

\section*{Self}
\subsection*{Reinforcement learning}

To match peoples behavoir, modifications to simple Rescorla-Wagner learning are common.

\section*{Both}
Many models combine information.

\subsection*{Experience-wieghted average}

\subsection*{Erev and Roth}

\end{multicols}
\end{document}