The Lightning Network for Dummies: Part 2

Lightning vs. Interledger Breakdown

Make sure you read Part 1 in the series to get up-to-speed.

Before even kicking this article off, I want people to know that this article has nothing to do with Ripple. I say this because I was biased in my initial evaluation of Interledger after hearing that it was invented at Ripple. It is now its own project within the W3C and is being developed as such. So, please, try not to bring that bias into the equation when reading this; this is for educational purposes, and it’s important people are aware of these distinctions.

When the first Interledger Escrow Payment was made, I recall having my mind blown and being incredibly excited for what would come of such innovation. At that time, it appeared really innovative and on the right track in regards to real interoperability.

First comment is me saying “This is huge”

Things got busy, and I figured why bother going deep on something made by Ripple. But Interledger came up again, recently, when Dan Robinson presented “HTLCs Considered Harmful” at the Stanford Blockchain Conference a few months ago and he mentioned some of the pros of Interledger and how they could be applied to Lightning. So, I decided to take a closer look.

This article provides a high-level of the main differences between both Lightning and Interledger, so they can quickly be digested and you can decide which is the superior technology.

Goals

Both Lightning and Interledger are payment networks with the goal of enabling cheap and fast payments (or, “micropayments”). The principle difference lies in the market that each is trying to address.

• Lightning —To provide for higher transaction throughput and lower transaction latency for the Bitcoin blockchain (and eventually enabling atomic interoperability between compatible implementations on other chains).
• Interledger — To serve as a protocol connecting blockchains and other ledgers.

Supported Assets

• Lightning — While Lightning was intended as a solution for Bitcoin scalability, it could very well support other currencies / assets via some bridge (Ex: drawbridge) allowing for the creation of the same UTXO inputs. That said, the protocol is defined in terms of Bitcoin scripts in BOLT #3, and doesn’t intend to support multiple currencies, so it’s fair to call it a single-asset network, for now.
• Interledger — Interledger’s was designed to be agnostic of features specific to various ledgers and instead build upon ledger abstraction so that it would be able to support multi-asset networks. (check out this neat little article on the features which have been discarded over the years).

Routing

• Lightning — To ensure privacy within the network, onion-routing is used to route transactions from the sender to the recipient. In doing so, nodes routing transactions are unable to determine a transactions path, sender, or recipient. This comes at the cost of anyone sending a transaction needing to know, a priori, a route with enough collateral to support their Lightning transaction.
• Interledger — ILP packets are routed in a manner similar to the Internet whereby the next hop is determined by the current recipient of the packet. Assuming a hierarchical network structure akin to that of the Internet, the sender will only need to know their local ‘router’ to route packets and to propagate across the rest of the network.

Channel Collateralization

• Lightning —All payment channels must be fully collateralized and sync’d with the network before they can interoperate in the network, so this is less of an issue in a live setting (aside from rebalancing your channels when necessary).
• Interledger — To avoid inefficiencies caused by creation and upkeep of an on-ledger escrow, payment channels on Interledger may operate on credit lines where participants elect the risk that they are willing to take with their peers.

Asset Transfer

• Lightning — Uses conditional transfers where the condition is enforced by the ledger, or, Hashed Time Locked Contracts (HTLCs), to facilitate payments in a non-custodial manner to their end destination.
• Interledger — Uses a generalization of HTLCs, Hashed-Timelock Agreements (HTLAs) which can be implemented over any type of ledger (even if those ledgers do not the ledger supports HTLCs), to facilitate packet transfer to their end destination.

Atomicity

Channels can only support transfers less than the amount of liquidity held within them. As such, the idea of packetizing payments or splitting them up into smaller concurrent payments is something which both technologies are working to address.

• Lightning —Atomic Multi-Path (AMP) Payments has been proposed and uses ‘extra onion blobs’ to allow for payments made in parallel. Effectively, it’s like Shamir’s secret sharing where each share is a partial payment and the recipient can only construct the pre-image after having received all of them.
• Interledger — STREAM is used to split transfers into small packets by default and routes across the network in parallel so as to mitigate congestion within channels which would be caused by large / in-flight transfers.

Final Thoughts

Ultimately, Interledger and Lightning are two different protocols seeking to accomplish somewhat similar goals but with very different target audiences.

Lightning is very in-line with the Bitcoin ethos and Interledger is aligning itself with the mindset of the existing legacy banking system of today, a half-step in the right direction. For this fact, I don’t see the two as competitors or intruding on each other’s missions.

Table of Contents

• The Lightning Network for Dummies (Routing and Capital Lock-Ups): Part 1
• The Lightning Network for Dummies (Interledger versus Lightning): Part 2

Thank you to Steven McKie (Editor) and Dan Robinson for your contributions and feedback to this article!