04-PaymentLayer.tex

\section{Payment Layer} \label{PaymentLayer}
HOPR nodes get paid for their privacy-enabling packet relay services via customized payment channels. In contrast to on-chain (layer 1) payments, payment channels have a number of properties that make them particularly suitable for the purpose of paying for privacy-preserving network traffic:

\begin{enumerate}
    \item \textbf{Cheap}: Opening and closing payment channels are the only on-chain interactions that cost transaction fees. All intermediate update transactions are exchanged in a P2P fashion without incurring settlement fees.
    \item \textbf{Fast}: After opening a payment channel, update transactions are not slowed down by the consensus layer (blockchain) as these transactions are signed off between both parties of the payment channel. Thus, the transaction throughput is decoupled from the blockchain and only limited by minimal processing and network latencies.
    \item \textbf{Minimal counter-party risk}: Either side of the payment channel can choose to close the channel at any time. However, the counter-party has some time to provide proof to the smart contract that they have a later update transaction with the signature of the other side. This allows each party to always settle on the latest balance on-chain. If the discrepancy between the closing transaction and the actual balance is less than the transaction fee of the closing transaction (gas) then it is not economically rational to send the later update transaction. This counter-party risk is however limited to the cost of the closing transaction which is a few cents today on the public Ethereum chain.
    \item \textbf{Minimal public metadata}: Since payments are not settled on-chain on a packet-by-packet basis but in bulk, the metadata is limited to the bulk information of how heavily a certain route in the network was used, e.g. on a monthly basis or whatever settlement interval the parties choose. Importantly, no linking between individual packets and payments, time or path is possible.
\end{enumerate}

\noindent Traditional payment channel implementations such as those used by \MYhref{http://raiden.network}{Raiden} are having a number of shortcomings that HOPR improves upon. Specifically, HOPR requires a payment channel architecture that allows for the following:

\begin{enumerate}
    \item \textbf{Pay for relaying}: Relayer should not be able to get paid for non-existing messages, i.e. they should not cheat the upstream node from which they receive the payment. This means that the payment and package delivery needs to be tightly coupled and one payment needs to be submitted per packet.
    \item \textbf{Proof of relay}: Relayer should not be able to get paid unless they have actually forwarded the package to the next downstream node. This requires cooperation between the receiving relayer and the next downstream node. Only upon confirmation of the next downstream node should the relayer receive their payment.
    \item \textbf{Partial payout}: Relayer should not be unduly punished for not being able to relay a package to the next downstream node. I.e. while they should not be able to get the corresponding payment for the packet that is thus lost, they should be able to get paid for the remainder of the successfully delivered packets.
    \item \textbf{Efficient settlement}: The relayer should have an efficient means of closing the payment channel. They cannot be required to submit individual proofs for each packet that they relayed as the on-chain transaction fees would be prohibitively high for relaying millions of packets.
\end{enumerate}

\subsection{Pay for Relaying}
HOPR overcomes the limitations mentioned above by embedding a customized payment channels. The update transaction of the payment channel is embedded in the header of a packet. The payment is, however, not redeemable for the receiving relayer without cooperation of the next downstream node. Consider the following example:

Alice is the sender of a private message and chooses a route via Bob and Charlie who are both relayers to Dave as the recipient.

In this case Alice will pay the entire amount for both relayers (Bob and Charlie) to Bob. Bob now needs to forward part of the payment (and the packet) to Charlie in order to get his payment. Charlie in turn needs to deliver the message to Dave in order to get her payment.