More specifically:
- What are the similarities and differences.
- Are the two technologies competing against each other?
- Are the two technologies cooperative (e.g., does it make sense to settle an ILP transaction using Lightning?)
5 Likes
Good questions. There are a lot of ways to compare the two projects / technologies but overall I would say that they:
- started in a somewhat similar place
- are trying to achieve fairly different goals
- work very differently today
- are technically complementary
- may compete for mindshare.
Goals
-
Lightning - Scale Bitcoin’s transaction throughput and lower transaction latency
-
Interledger - Connect all currencies and ledgers in the world
-
Both - Enable fast, cheap payments and micropayments
Technical Starting Point
- Both - Chaining hashlocked transfers together enables multi-hop payments through untrusted intermediaries
Privacy vs Efficiency
-
Lightning - All transactions are onion-routed by default to keep user transaction history private even from the nodes routing the payments. As a result, packets must be source routed, meaning every node needs a full and up-to-date view of the entire network
-
Interledger - ILP packets are meant to take the most efficient path through the network and are not relayed through more hops than needed. Like the Internet, routing decisions are made at each hop so nodes do not need a full view of the network. Onion routing or mix networks can be built on top of the core protocol, just as TOR is built on top of the Internet.
Update: See this thread for more details on Payment Privacy with Interledger.
Currency / Asset Support
-
Lightning - Arguably, Lightning has many design choices that make it more suited to a single-asset network than a multi-asset network. For example, the fact that all nodes need an up-to-date view of the network may be feasible with a single currency and infrequently updated prices, but it is infeasible for constantly changing cross-currency exchange rates. Additionally, Lightning’s long hashlock timeouts would create a strong incentive to exploit the “free option” problem and steal from nodes providing cross-currency liquidity. For more details see HTLCs Considered Harmful and this thread from the Lightning mailing list on An Argument for Single-Asset Lightning Network.
-
Interledger - Many of the design choices that shaped Interledger were specifically intended to enable it to efficiently and safely handle multiple assets. For example, Interledger uses Internet-style non-source routing so that nodes do not need to constantly broadcast their changing exchange rates throughout the network. Also, Interledger switched from ledger-enforced hashlocks to connector-enforced hashlocks to reduce the required timeouts and minimize the free option problem. See Simplifying Interledger: The Graveyard of Possible Protocol Features for more details on the tradeoffs and logic behind them.
Ledger Integrations
-
Lightning - The protocol is defined in terms of Bitcoin scripts and specific features have been required and proposed for the Bitcoin ledger in order to support Lightning, such as SegWit and SIGHASH_NOINPUT. Connecting Lightning to ledgers that are not forks of the Bitcoin codebase would likely require reimplementing Bitcoin scripts on top of the other ledger.
-
Interledger - Designed from the start to connect all of the blockchains and other types of ledgers in the world, Interledger was meant to be completely agnostic to specific ledger features and instead was built upon a ledger abstraction. As it developed, the abstraction was simplified to the point where the only feature required to integrate a ledger is that it supports simple transfers between accounts (and even cash – a “ledger” without an API – can be used).
Collateralization and Credit
-
Lightning - All payment channels are fully collateralized and each node must tie up liquidity in each channel to cover the total value of transactions that can be routed through that channel without balanced bilateral flows or an on-chain transaction.
-
Interledger - Each bilateral link may be fully collateralized or may operate on limited credit lines. Importantly, the chained hashlocks used by both Interledger and Lightning isolate risks so that each node can only be affected by the arrangements they make with their directly connected peers. See Hashed Timelock Agreements (HTLAs) for more details, but note that on-ledger escrow is no longer used due to performance reasons.
Atomicity vs Packetization
Each bilateral link or payment channel has a limited capacity based on how much liquidity (money) the parties allocate to that link. There are different strategies for enabling larger payments to be sent through links with lower capacity:
-
Lightning - With the proposed Atomic Multi-Path (AMP) Payments approach, a larger payment sent through Lightning would be split into multiple concurrent transfers and each “split” would be held by the receiver until they receive the total amount.
-
Interledger - Like the Internet, Interledger splits larger transfers into smaller packets and sends them as quickly as the network can support (meaning it could be all at once or one at a time). The parallel is so strong that the STREAM protocol built on ILP uses congestion control algorithms directly inspired by those used in the Internet’s TCP. Interledger prioritizes fast, simple forwarding to avoid allowing nodes to tie up large amounts of the network’s liquidity for payments that may or may not be executed.
Layer 2 vs Layer 3
-
Lightning - The network is most often described as a “Layer 2” technology built on top of Bitcoin (the “Layer 1” blockchain).
-
Interledger - The protocol can be used to connect different Layer 2 scaling technologies, including but not limited to the Lightning Network, Ethereum’s Raiden Network, and XRP Payment Channels. The core Interledger Protocol (ILP) is a “Layer 3” protocol, and the Interledger stack includes Layer 4 and 5 protocols built upon it. See Layer 3 Is for Interoperability for more details of the stack.
17 Likes
that is such a helpful, thoughtful answer…thank you.
1 Like
I’d also point to Connector Risk Mitigations to get a better idea of how “HTLCs are Considered Harmful” and to get some explanations with examples, written in mind with how Lightning operates!
Lightning and Interledger are both payment networks. They differ primarily in their network requirements which in turn dictates the addressable market for each system.
The addressable market for Lightning is limited because the network requirements, which govern organizational priorities, result in an uncompetitive payment system at very large scale. Lightning will not be a global payment system and there seems to be a lot of confusion on this point. Lightning will be a payment network which incrementally expands the capabilities of Bitcoin (only), it’s a local rails and that is completely fine, it’s just important to understand the scope.
Here’s a brief breakdown of the main network requirements for the Lightning network and their consequences:
(1). Every bi-lateral relationship is fully collateralized. This requirement results in at best a 1:1 clearance-to-collateral ratio; as a comp, the UK in 2008 cleared ÂŁ784B with ÂŁ32B of Central Bank reserves (25:1). Higher collateral requirements directly translate to higher network usage fees. This can be remedied by Lightning lessening the requirement, it is not a priority or being developed.
(2). Multi-hop payments are the default. Lightning has prioritized “routed payments [as] a first-class citizen” (link). Multi-hop payments with relatively homogenous collateralization amongst nodes compounds (1) because for every N hops we are locking up a 1:N clearance-to-collateral ratio. An alternative could be to allow a hub-and-spoke model to reduce hops (perhaps enabling trusted hubs to exchange IOUs for capital efficacy).
Lightning stakeholders championing the network as a global solution, base on these requirements alone, in my opinion, represent a gross misunderstanding of modern financial systems.
(3). Enforcing atomicity in cross-ledger transactions comes with a host of concerns (link) most of which are largely mitigated by streaming micropayments (link). It’s highly unlikely Lightning expands competitively beyond Bitcoin.
(4). Bitcoin operational risk. Bitcoin does not have the block size to open and close a very large number of channels. Increasing blocksize is not an organizational priority, it would require a hard fork, and that proposal has already failed once (link). Ethereum, for example, does not have the block space either but their community has a plan, so you’re just betting on execution.
(5) Source-routing is unlikely to work at scale. It is hard for nodes to keep an updated view of the entire network and there is no evidence this can be done at scale. This concern is compounded by (2).
(6) Poor UX. Onboarding and reloading takes one hour. Multi-hop payments will likely take 5-10 seconds. This is far away from fast/instant UX expectations delivered by modern payment systems. (Lesser concern but as a practical standpoint today onboarding is a huge problem because clients need to run a full node and the tech for light clients is limited).
It is also unfortunate that the development timescale to see these results is long (3 years and not 3 months).
Lightning likely results in a fine incremental scale to Bitcoin. If participants wanted more, network requirements would need to change. Payments are a commodity, so perhaps client pressure for cost reduction may resort in out-of-network IOUs to remain competitive or forced hubs in network topology.
In contrast, Interledger network requirements and organizational priorities are aligned with the goal of becoming an alternate global payment system. Interledger and Lightning address different problems, they are not competitive. Lightning developer are doing good work and the network will likely be one of many local rails to Interledger.
As a final point, from a systems perspective, it is useful for a generalized system to allow for pricing of relevant variables and scoping of concerns. Interledger allows clients to price risk, instead of assuming it is infinitely expensive. Interledger isolates major concerns, allowing for flexible upgrading, instead of coupling all concerns in-protocol. Lightning may expand the usability of Bitcoin but it lacks the fundamentals to be a global payment network. Teams should build accordingly.
8 Likes
This thread has a lot of valid points. Let me add a remark that LN’s requirement to liquidity could be improved with XLN proposal XLN: Extended Lightning Network. TL;DR LN is prepaid (full-reserve)… | by Egor Homakov | Fairlayer | Medium that like Interledger combines credit limits with collateral (“Each bilateral link may be fully collateralized or may operate on limited credit lines”).
Also, XRP’s payment channels are unidirection and are unlikely to be useful in Interledger, as only bidirectional channels are able to form a usable network. XRP has payment channels “on paper” in an unusable way but not in reality.
Payments are a commodity, so perhaps client pressure for cost reduction may resort in out-of-network IOUs to remain competitive or forced hubs in network topology
Out-of-network IOUs as an addition to collateralized balances is a proposal in XLN, but “it is not a priority or being developed” unfortunately, yes!
XRP’s payment channels are unidirection and are unlikely to be useful in Interledger, as only bidirectional channels are able to form a usable network. XRP has payment channels “on paper” in an unusable way but not in reality.
They are being used today?
You can form a bidirectional channel from two unidirectional channels. There are significant advantages to unidirectional channels, such as the ability for the recipient to pull owed funds instantly from the channel at any time. Given the low cost and high throughput of the XRP Ledger, you can create two channels more quickly and more cheaply than creating one bidirectional channel on most other ledgers.
10 Likes
Welcome to the Interledger Forums!
Just for clarity, two unidirectional channels aren’t exactly equal to a bidirectional. But for XRP it isn’t much of a problem due to the speed of top up and channel close.
Bidirectionals are nice if you’re doing a lot of back and forth trading as they can continue indefinitely (within the collateral bounds). Two unidirectionals will eventually run out of spendable collateral.
Although as @JoelKatz mentions bidirectionals can’t do (non cooperative) instant closes.
2 Likes