-
Notifications
You must be signed in to change notification settings - Fork 84
Lightning Network
From original paper (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 (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 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 level). this problem means that in practice lightning nodes becoming custodial for those funds.
eltoo is a novel protocol proposed as an evolution for the lightning protocol and more generally other layer 2 solutions. Reading eltoo 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.
This paper 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.