# Layer 2 solutions ## Lightning Network From [original paper](https://lightning.network/lightning-network-paper.pdf) (which according to Orfeos is somewhat outdated). The core idea of _Lightning_ is to separate the signing and creation of transactions from the actual broadcasting to the blockchain. Each bi-partite _payment channel_ maintain the balance of the 2 parties through a _pair of exclusive commitment transactions_ where each member of the pair can be posted by only one party, with outputs constructed in such a way that the other party can receive the _total amount_ in the channel should the transaction be posted illegitimately. When 2 parties want to do some payment, they can agree to construct a new pair of _commitment transactions_ and reveal the private key for their _revocable delivery output_ so that each party can then build a _breach recovery_ transaction: If a party posts an old _commitment_ transaction, the counterparty can immediately post this breach recovery transaction and thus get all the money of the payment channel. A _lightning network_ is needed when one wants to send money to another party to which it has no direct payment channel. This is made possible by constructing a [Hashed Timelock Contract](https://medium.com/liquality/hash-time-locked-contracts-htlcs-explained-e88aa99cc824) (sometimes called _Hash & Time-lock Contract_) which is tied to one output of the commitment transaction. This contract ensures the output can only be spent if one provides a value _R_ which is the preimage of a known _hash(R)_ value, within a certain time limit. The fact that R is known only by both parties makes it possible to _route_ the payment through other nodes without running the risk of money being stolen. The trick is to decrease the timeout for the HTLC for each hop traversed. There is a whole section of the paper devoted to various attacks analysis and threat modelling. The main "problem" of _Lightning_ is that parties must constantly monitor the network in order to be able to detect and counteract any fraudulent (or simply wrong) behaviour from a counterparty. An article on [Lightning's dirty little secret](https://medium.com/@peter_r/visualizing-htlcs-and-the-lightning-networks-dirty-little-secret-cb9b5773a0) delves into the practice of lightning and actually shows there is some amount of trust built into it for very small payments (below the [dust](https://medium.com/@peter_r/visualizing-htlcs-and-the-lightning-networks-dirty-little-secret-cb9b5773a0#:~:text=Here%E2%80%99s%20the-,problem,-%3A%20if%20the%20value) level). this problem means that in practice lightning nodes becoming [custodial](https://medium.com/@peter_r/visualizing-htlcs-and-the-lightning-networks-dirty-little-secret-cb9b5773a0#:~:text=a%20hub%20has-,effectively,-custodial%20control%20over) for those funds. ## Eltoo [eltoo](https://blockstream.com/2018/04/30/en-eltoo-next-lightning/) is a novel protocol proposed as an evolution for the [lightning](https://lightning.network/) protocol and more generally other layer 2 solutions. Reading [eltoo](https://blockstream.com/eltoo.pdf) paper as suggested by Orfeas Stefanos. He also found the original lightning paper pretty undigestible... It works in 3 phases: _setup_, _update_ and _settlement_ * _setup_ : One party (the _funder_) crafts a transaction with a _multisigned_ output that can only be spent by a transaction signed by the involved parties. This requires 2 keys from each party: one update key Ku and one settlement key Ks. Prior to posting this transaction, it requires a multisigned transaction from all other parties that returns the fund it just posted (this is the initial _settlement_ transaction). The output from funding transaction has 2 possible spending paths: either wait for X blocks and pay to a tx multisigned with the Ks, or pay immediately to the Ku. * _update_: Parties can create _update transactions_ which consume the funding output and create a new one, possibly redistributing the funds in the channel to create other (non-multisigned) outputs. The "state threading" output of the update transaction has a _State index_ hash constraint which allows it to be consumed by any update transaction with a greate _state index_. Update txs are so-called "floating transaction" that can consume any transaction with a lower index. Also, each new update transaction must be signed by a new Ku which is derived from the initial Ku so it's easy for anyone to check an update tx is valid * _settlement_: The settlement tranasction consumes the last update transaction's output and closes the channel The protocol relies on some modifications to the blockchain protocol: Adding the ability to sign a transaction without including some inputs so that the transaction can stay valid if attached to another, validated by script, output. This is obviously needed to ensure all update transactions stay valid. This protocol seems very similar to how Hydra head works, esp. for the close/contest phase: Consensus between parties is established by multisigning all transactions, and there is an index (snapshot for hydra head, state number for eltoo) that is used to ensure more recent snapshots take precedence ; also, there is a timeout (contest period) to ensure all parties have a chance to react to misbehaving node. ## Channel factories [This paper](https://tik-old.ee.ethz.ch/file//a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf) which is written by authors of the _eltoo_ protocol extends the principles of eltoo to multiparty or even hierarchical payment channels: Have a funding transaction where all parties commit some funds into a multisigned output, then updates the balances through timelocked (or penalty based) _commitment_ transactions until settlement is done. Only the _funding_, final _commitment_ or _settlement_ need to happen on-chain. The main contribution of the paper is to separate funding transaction in 2 parts: an on-chain _hook_ transaction involving multiple parties, and an off-chain _allocation_ transaction that effectively creates off-chain the various (bi- or multi-partite) channels which can then be used for _commitments_ by involved parties. This scheme allows for trees of channels, with the possibility of moving funds around by replacing older _allocation_ transactions with new ones thus closing previous channels (off-chain or on-chain depending on the level of collaboration of parties). Participants who go offline can later rejoin or the remaining participants can recreate new _allocations_ excluding the previous participant through an on-chain transaction.