.jpg)
Check our our first piece in the series: Blockchain Is Stuck in the 80s
Here’s something you might not know: both the Interledger and Lightning protocols were birthed independently from the same fundamental insight.
At the time, we called it cascading transfers. Lightning called it hashed timelock contracts (HTLC).
The result is that both Interledger and Lightning are theoretically suited to solve the problem of blockchain interoperability. But context is important. Lightning was designed with another purpose in mind. That doesn’t rule out its future as an interoperability protocol, but it does make that path far less likely.
Lightning was originally created to solve Bitcoin’s well-documented core problems: high fees and scalability. Bitcoin can handle about 7 transactions per second. Compare that to Visa at 37,000. Lightning addresses this bottleneck by batching transactions off-chain.
Part of the reason for this is that Bitcoin is hard to upgrade as a decentralized, open-source initiative, as well as being the first-ever blockchain. As an early Bitcoin contributor, it’s something I’ve experienced intimately firsthand—from getting consensus among key devs to getting miners on board to getting everyone to upgrade. Even minor changes can take a year or more.
Moreover, there will always exist a purist contingent of supporters who believe that the Bitcoin blockchain is already “perfect”—fueled in part by the enduring mystique of Satoshi Nakamoto. There’s a kernel of truth there. Bitcoin is the chain that’s been thought about most deeply, and it’s also the most fleshed out and developed. Additional changes to Bitcoin’s core code have the potential to undermine its reliability and thus leadership in the space.
As a result, Bitcoin’s core framework is unlikely to see dramatic changes in the foreseeable future. Instead, the blockchain must rely on off-chain solutions in order to stay relevant versus newer, faster, and more feature-rich alternatives.
That’s essentially Lightning’s purpose as a Layer-2 protocol for Bitcoin.
As such, much of Lightning’s focus has been on Bitcoin scalability, although more recently, there have been developments in the ecosystem that focus on other features, such as support for stablecoins and DeFi on the Bitcoin network.
All of which is fine, but it means that blockchain interoperability has always been a bit of an afterthought in terms of Lightning’s developmental roadmap. Blockchain interoperability was an early talking point, and Lightning quickly ported to Litecoin along with Bitcoin—an easy lift given Litecoin’s shared heritage. But this still doesn't allow transactions between the two networks. Since then, it’s been relatively quiet on the interoperability front over the last few years.
Meanwhile, Interledger was created from day one with a singular purpose: Let’s solve the problem of interoperability—not just with blockchains but with all ledgers.
Since the first altcoins appeared, the blockchain ecosystem has always been a tribal place. Along those lines, Lightning’s allegiance to Bitcoin is hardly surprising.
Here’s Lightning Labs CEO and founder Elizabeth Stark speaking at Bitcoin 2022 back in May, referenced by a TechCrunch feature entitled, Bitcoin’s bid to become the ‘one chain to rule them all’:
“People want access to Bitcoin, the asset … When you’re looking at stability, security and the global payments use case, and the global transaction aspects, that’s where Bitcoin and the Lightning Network will shine,” Stark said.
Of course, Lightning Labs is just one company within the ecosystem—albeit a major one—contributing to the development of the protocol, but the idea that this is all about Bitcoin is pervasive within the community. Lightning is sometimes framed as a way for Bitcoin to compete with Ethereum.
It’s not necessarily a problem that Lightning and Bitcoin are attached at the hip, but it does raise practical questions about the ecosystem’s interoperability roadmap. There are strong incentives for Bitcoin maximalists to deter interoperability initiatives within the community that potentially level the playing field for other ledgers. If you’re coming from a Bitcoin-centric world, you would likely prefer less competition—not more.
While Interledger was originally created as a research project during my time at Ripple, it was designed to bridge the gap between blockchains and decades-old bank ledgers, so it has always been technologically agnostic from day one.
Lightning’s priorities are reflected in its technical and design decisions. Lightning requires very specific transaction semantics and advanced payment channel support in order for systems to participate. These were included in Bitcoin’s SegWit and Taproot updates, which Litecoin received as well soon after, allowing them to integrate with Lightning.
It would be an arduous endeavor for other ledgers to support that functionality. While there are ways to implement Lightning using smart contracts, which some have experimented with on Ethereum, not all chains are flexible enough to go down that implementation path. Even if they are, it’s hardly a straightforward path. Programmable chains would need to replicate Bitcoin’s behavior to a tee, requiring smart contracts that would be difficult to get right.
Other chains would need to fundamentally change how their ledger works. For many, that’s a nonstarter.
Even in a world where many more chains had their own Lightning networks, that would still only be a small fraction of the problem. There’s still the additional mountain to climb to enable cross-network transactions.
In the Lightning network, transactions use very long timeouts in order to give nodes enough time to redeem funds on the underlying blockchain in case a peer goes offline. Due to Bitcoin's very long delay between blocks (about 10 minutes), the overall timeout for a Lightning transaction can be on the order of hours. During this time, an attacker has the option to either complete the transaction or cancel it. This creates a free-option problem. Namely, an attacker could choose to complete transactions if the exchange rate moves in their favor and cancel them if it doesn't.
To tackle this problem, Interledger's timeouts are in the range of seconds instead of hours. By making the timeout orders of magnitude shorter, options are much less valuable. Interledger also intentionally uses a relatively low limit on the amount per packet, choosing instead to split large transactions into many small packets. This is similar conceptually to the way a large file sent over the Internet is split up into tiny pieces to be transferred. By limiting the amount of money in-flight at any given time, the value of the free option is reduced further. Keeping the option value very low means that due to transaction fees, options are only worth exercising during rare incidents of extreme volatility, which makes them a negligible cost to the network.
These examples show how Interledger was optimized from day one for interoperability. We took inspiration from the design of internet protocols and made Interledger incredibly simple, which reduces obstacles for implementation and increases efficiency.
The only requirement for a ledger or other transactional system to participate with Interledger is that value can be transferred from one person or entity to another. Advanced features like payment channels aren’t a requirement, but where they exist, Interledger can maximize them.
We love using the example that even physical transactions could work with Interledger—say, one person handing another a bar of gold. Obviously, it’s an unlikely scenario, but it helps illustrate that Interledger transactions can be settled in a variety of different ways.
That flexibility also applies to levels of trust.
Lightning takes a narrow approach, focusing purely on anonymous peer-to-peer transfers, and to Lightning’s credit, it’s very well optimized for that trustless context.
But in the broader context of real-world finance, not everyone is anonymous and trust is actually very beneficial. One way to think about it is that trust means credit, and credit means lower capital requirements. The more trust that exists between two parties, the less collateral they need to provide. This reduces the overall cost of their transactions, offering savings that can be passed on to the end user.
In a sense, Interledger takes a more general approach—it works both ways. You can optimize for varying levels of trust, use cases, and circumstances just by tweaking protocol parameters.
None of this is meant as a criticism of Lightning. By all indications, it’s a well-executed project with a strong purpose and use case. As a long-time Bitcoin holder, I’m thrilled about Lightning’s progress and potential. But I don't see it solving the problem of interoperability on its current trajectory.
In that way, Lightning and Interledger are quite complementary to each other. For example, we’ve leveraged Lightning for Interledger’s Bitcoin integration in the past and plan to revive that project soon. In that sense, Lightning helps address Bitcoin’s scalability and transaction fee problem, while Interledger helps connect Bitcoin to other chains.
Bitcoin has historically served as a rising tide for the crypto ecosystem at large. This would only continue that trend. Lightning could conceivably make it more attractive to participate in the larger Interledger ecosystem via a Bitcoin wallet.
The next post in this series will examine how the ILP stack fits together while taking a closer look at what's next for the protocol.
Special thanks to Alec Liu for his editorial contributions to this piece.
Lightning requires specific transaction semantics and advanced payment channel support for systems to participate, which is an interoperability problem. Interledger was created from day one with a singular purpose: to solve the problem of interoperability—not just with blockchains but with all ledgers.
Read the full articleWatch the video
