# Perun <> Fiber interoperability
In this document, we give an overview of the two channel (network) technologies Perun and Fiber.
In particular, we will investigate opportunities for interoperability between the two technologies.

## Advantages of Fiber
- Lightning-like htlc-based protocol
- Possibility for convenient Bitcoin interop due to similarity of Protocols
## Advantages of Perun
- Blockchain agnostic (aside from CKB there are deployments on Ethereum & sidechains, Polkadot, Stellar, …)
- Easy interoperability support (demonstrated in the form of PerunX for Ethereum <> side-chain, Ethereum <> Stellar), with plans to support CKB <> Ethereum.
- Multi-hop with less interaction: On Perun, multi-hop is facilitated through “virtual channels”, which allows to essentially treat parent channels as a ledger and recursively build more channels on top of them. Hence, in multi-hop channels end-points can exchange multiple transactions without the need to involve intermediaries for every single transaction. Virtual channels come with some other benefits. For instance, they do not need any decrement in timeout along the path.
- State channel support: Perun channels support custom logic and additional transaction state, which enable off-chain smart contracts and conditional payments. We will exploit this functionality for interoperability purposes.

## Advantages of Perun <> Fiber interop
Due to their particular sets of strengths, it seems that Fiber is an ideal solution for interoperability with Bitcoin, while Perun seems to offer more interoperability with account-based chains like Stellar or Ethereum. By allowing seamless transaction interoperability between Fiber and Perun, one would open opportunities to place CKB as a strong interoperability layer between Bitcoin and Ethereum, which seem rather disjoint otherwise.

## Techniques
As a start, we propose atomic swaps between Perun and Fiber channels on CKB as an interop layer.

## Atomic Swaps
The atomic swap scenario is the simpler one. Suppose that two users Alice and Bob share a Perun channel $PC_{ab}$ as well as a (direct) Fiber channel $FC_{ab}$. We deal with a scenario, where Alice and Bob want to update both channel states **atomically**. One major application is **rebalancing**: Suppose that Alice has lots of funds in $FC_{ab}$ but no more funds in $PC_{ab}$. Then, they could update both channels atomically, with the following payments: $x$ coins from Alice to Bob in $FC_{ab}$ and $x$ coins from Bob to Alice in $PC_{ab}$. While this seems vacuous on its own, it can be a powerful tool, when considering that both $FC_{ab}$ and $PC_{ab}$ may be parent channels in the two respective channel networks, since rebalancing channels can be a fundamental challenge for channel networks.
Essentially, the atomic swap is a transaction between Alice and Bob that can draw funds from **both** channels, but is still carried out as a single transaction conceptionally.

### Realization Ideas
The first option is to use the adaptor-sig based idea originally designed for Lightning <> Perun (https://hackmd.io/WzEaAoKkTQaF-rbTJ1jCfA) as it works identically for Fiber <> Perun. Henceforth we will assume familiarity with the document linked above. The adaptor-sig based approach, however, requires the use of adaptor signatures and assumes that there is always one party **who does not lose money on Fiber**. While this assumption should almost always hold in practice, we nevertheless explore alternatives, especially to avoid complexities introduced by the use of adaptor signatures.

Generally, problems can arise, whenever one party (with the corresponding incentive) can finalize the two channels in different states. Roughly, we can prevent this making use of conditinal payments as can be implemented in Perun. Suppose both channels are in state $i$ (knowing that version numbers are meaningless in Fiber, we just use it for notation). Let $(pk_A^F, pk_A^P)$ be Alices public keys in Fiber and Perun respectively, and similarly for Bob. Let $r_A$ be Alice's revocation secret for state $i$ in $FC_{ab}$ and $r_B$ accordingly (preimage). Further, let $C_A$ and $C_B$ the corresponding hash challenges.
- Parties prepare $\mathsf{Com}_A^{i+1}$ and $\mathsf{Com}_B^{i+1}$ with the new Balance distribution in $FC_{ab}$. Let $H_A$ be the hash of$\mathsf{Com}_A^{i+1}$ and $H_B$ be the hash of $\mathsf{Com}_B^{i+1}$.
- Prepare the Perun state $s_{i+1}$. Add to the data field: $(H_A, H_B, C_A, C_B)$. Add the following condition to the state: The state is only valid, if the following condition holds:
- When submitted by party A: supplied witness $w = (\sigma_A, r_A)$ such that $\mathsf{Verify}(pk_A^{F}, \sigma_A, H_B) = 1$ (i.e. Alice supplied a valid signature on Bob's new commit transaction), and $H(r_A) = C_A$ (i.e., Alice revokes her old state in $FC_{ab}$).
- When submitted by party B: supplied witness $w = (\sigma_B, r_B)$ such that $\mathsf{Verify}(pk_B^{F}, \sigma_B, H_A) = 1$ (i.e. Bob supplied a valid signature on Alice's new commit transaction), and $H(r_B) = C_B$ (i.e., Bob revokes his old state in $FC_{ab}$).
- Exchange signatures on $s_{i+1}$.
- Alice signs $\mathsf{Com}_B^{i+1}$
- Bob signs $\mathsf{Com}_A^{i+1}$
- Parties exchange $r_A$ and $r_B$

#### Advantages
- No need for Adaptor Signatures
- Guarantee that every party can always make both channels end in the same state. The previous protocol allowed that Bob can cause the channels to end in $i+1$ on FC and $i$ on PC. Thus the necessity for the assumption that Alice does not lose money on FC (i.e., $coins_{A, i+1}^{FC} \geq coins_{A, i}^{FC}$).

#### Requirements
- Conditional Payments in Perun (possible, but need to be implemented)
- We assumed theat $\mathsf{Com}_A^{i+1}$ is actionable through 2 signatures on $H(\mathsf{Com}_A^{i+1})$ (by Alice and Bob).
I am not sure how that works exactly in the fiber scripts, but essentially one needs to replace $H_A$ and $H_B$ in the Perun state by any value that, when signed by both parties, makes the respective commit transactions actionable. Ideally this would be a hash for short on-chain states.
- The timelock in $PC_{ab}$ needs to be shorter by in Perun than in Fiber by an appropriate amount for the following reason: Suppose a malicious Bob, does not send $r_A$ but instead posts $\mathsf{Com}_B^i$ onchain, starting the timelock $t_{FC}$. Then Alice would have to post $s_i$ on-chain on Perun immediately, starting $t_{PC}$. Suppose that $t_{FC} < t_{PC}$. Bob can run the following attack:
* Bob waits until $t_{FC}$ is expired and moves the funds out of the commit transaction. He now can no longer get revoked on Fiber.
* Since $t_{PC}$ is not yet expired, he can post $s_{i+1}$. While he is forced to reveal $r_B$ in the process, the revocation is no longer actionable.
Hence, we require that $t_{PC} < t_{FC} + x$, where $x$ is an upper bound on the time required by a party to:
- observe the $\mathsf{Com}_B^{i}$ transaction
- issue the Perun transaction for $s_i$
- observe the Perun transaction for $s_{i+1}$, learn $r_B$
- Issue a punishing transaction consuming $\mathsf{Com}_B^i$ using $r_B$
Should the respective timelocks not fulfill this requirement, one can (a) update $FC_{ab}$ once initially changing the timelock appropriately, or (b) update $PC_{ab}$ once initially changing the timelock appropriately. This operation is currently not supported in Perun, but can be implemented (with care).

#### Security
To establish security, we inspect possible attack vectors at different stages of protocol execution.
We consider an attack successful, if a party either manages to successfully close the two channels in different states, or if a party manages to "freeze" any of the channels in a state (preventing their peer from closing the channel at all).

After exchanging the commit transactions and preparing the new Perun state, there is no potential for exploitation, as the old state is still valid and neither party can go on-chain with the new state in any channel.

The first interesting step comes, when one party, say A, sends their signature on the new Perun state $s_{i+1}$ to their peer (Bob).

At this point Bob, could run the following attack: Register the Perun channel $PC_{ab}$ in state $i+1$: In this case, Alice immediately learns Bobs signature $\sigma_B$ on $\mathsf{Com}_{A}^{i+1}$ as well as Bob's revocation pre-image for the FC channel's old state $r_B^i$. Given $\sigma_B$, Alice immediately puts $\mathsf{Com}_A^{i+1}$ on-chain. If this is successful, both channels close in the new state. The only way for this to fail is if Bob is faster than Alice and consumes the on-chain cell of $FC_{ab}$ by submitting $\mathsf{Com}_B^{i^*}$ for some $i^* < i+1$. In this case, Alice tries to punish Bob in $FC_{ab}$ for submitting an outdated state. If $i^* < i$, then Bob is publishing a state that has been outdated even prior to the swap, which means Alice can trivially punish him with the corresponding revocation secret. On the other hand, if $i^* = i$, then Alice can parse the corresponding revocation secret from Bob's transaction registering $s_{i+1}$ in $PC_{ab}$ (recall that, for this transaction to succeed, Bob must have supplied as witness the revocation secret $r_B^i$ of $\mathsf{Com}_B^i$.

To highlight another important detail, consider the case that Bob just goes offline instead. How can Alice check out in state $i$? In this case, Alice neeeds to submit $s_i$ **first**, and only publish $\mathsf{Com}_A^{i}$ *after* the timelock for $s_i$ expired. If Alice publishes $\mathsf{Com}_A^{i+1}$ any earlier, then Bob could dispute in $PC_{ab}$ with $s_{i+1}$ immediately afterwards and Alice could not punish him, because *her* commit transaction of the outdated state is already registered in $FC_{ab}$.

The next interesting point in the protocol security-wise occurs after Alice sends her signature on $\mathsf{Com}_B^{i+1}$, i.e. the signature on Bobs commit transaction for the new state of $FC_{ab}$. First, Note that, at this point Alice must have already received a valid signature on $s_{i+1}$ by Bob.
Now, Bob could try to register the new state in $FC_{ab}$, and the old state in if $PC_{ab}$. To do so, Bob publishes $\mathsf{Com}_B^{i+1}$ on-chain, which would cause Alice to register $s_{i+1}$. If Bob, however, manages to publish $s_i$ first, Alice can just dispute with the more recent state $s_{i+1}.$

#### Multi-Hop
Clearly, the same approach works works, whenever $PC_{ab}$ is a virtual channel. However, we need to explore what happens, if $FC_{ab}$ is not a direct channel, but instead a multi-hop channel. In particular, we need to explore how this technique can be adapted to work with HTLC updates.

## Future Direction: Cross-Network Transactions
While atomic swaps are a powerful tool, we ultimately envision Perun <> Fiber interoperability to allow for cross-network transactions, that allow to span virtual (or multi-hop) channels across intermediaries. Consider the following scenario:
User A has a Fiber channel with Hub H, and user B has a Perun channel with Hub H.
Suppose, initially A owns asset X in the current state of $FC_{AH}$ and H owns the same asset in $FC_{BH}$.
User A now wants to issue a cross-network transaction off-chain, such that after the transaction, user B owns asset X in $PC_{BH}$ and H owns asset $X$ in $FC_{AH}$.
One can consider this to be a more general version of an atomic swap (i.e., a multi-hop payment), and a special case of a virtual channel with only one payment issues.

The challenge in achieving this semms to be designing a mechanism that allows to atomically update a Perun and Fiber channel with different sets of participants ($\{A, H\}$ and $\{B, H\}$).
Ideally, any solution would be expandable to full-fledged Perun-style virtual channels, which would allow us to expand the technique to cross-network transactions that cross more than one intermediary hop.

## Opportunities from PTLCs
We note that Fiber channels could be extended to support "Point" timelocks (PTLCs) instead of Hash timelocks (HTLCs) as revocation mechanisms. Instead of generating revocation keys roughly as $(H(pre), pre)$, where $H$ is a hash function, point timelocks instead use hardness of discrete logarithms in certain groups to build a suitable one-way function $(g^{pre}, pre)$, where $pre \in \mathbb{F}_p$ and $g$ is the generator of a cyclic group of prime order $p$ where dlog is hard.

One crucial step when trying to update Perun und Fiber channels atomically is to ensure that the new Perun state cannot become valid when the old Fiber state is not yet revoked (and vice-versa). Since Perun's update mechanism is signature exchange, which in the case of Schnorr signatures is based on a similar group structure, moving to PTLCs could allow to exploit this structure to efficiently design protocols that atomically sign a new Perun state, Fiber state, and revoke the old Fiber state.