Onpode
Cover art for Why Lightning and Rollups solve scaling differently — and which tradeoff wins depends on the use case

Why Lightning and Rollups solve scaling differently — and which tradeoff wins depends on the use case

October 25, 2026 · 13 min

Iris Holm & Cyrus Reed

Iris, hey — okay, I have to tell you, I spent part of yesterday trying to send someone forty dollars and it took, like, three separate apps and I still don't know if it arrived. That's the whole episode, actually. Wait — is it? Because that's what I kept thinking, like, why is moving money…

Payment channels and rollups represent two structurally distinct Layer-2 approaches to blockchain scalability, each making different tradeoffs along the dimensions of throughput, composability, privacy, and on-chain footprint. Payment channels, most prominently implemented as the Lightning Network, allow two parties to lock funds on-chain once and then transact repeatedly off-chain.

0:0013:12
Get the next episode on Crypto →

Follow it free — new episodes land in your feed.

Or make your own — any topic, in minutes

More Onpode episodes on Crypto →

About this episode

Payment channels and rollups represent two structurally distinct Layer-2 approaches to blockchain scalability, each making different tradeoffs along the dimensions of throughput, composability, privacy, and on-chain footprint. Payment channels, most prominently implemented as the Lightning Network, allow two parties to lock funds on-chain once and then transact repeatedly off-chain.

Grounded in 11 sources
Ethical Risk Analysis of L2 Rollups | ACM Transactions on the Web ↗ · dl.acm.org
Ark: Offchain Transaction Batching in Bitcoin ↗ · doi.org
Balance Disclosure in Payment Channel Networks Using Noiseless Privacy ↗ · doi.org
Utility-Based Routing in Payment Channel Networks: A Tradeoff Between Utility And Privacy ↗ · doi.org
Probing Channel Balances in the Lightning Network ↗ · semanticscholar.org
Hijacking Routes in Payment Channel Networks: A Predictability Tradeoff ↗ · semanticscholar.org
Lightning Network Capacity Hit All-Time Highs—But Growth Is Coming From Exchanges, Not Users. Is Bitcoin's Payments Layer Becoming Another Institutional Rail? - General - Web3 Developer Forum ↗ · blockeden.xyz
How does the Bitcoin Lightning network actually work? ↗ · blog.bitbox.swiss
State Channels vs Rollups: Off-Chain Scaling Explained ↗ · chainstarter.co.uk
Layer 2 Explained: Scaling Blockchains & Cutting Gas Fees ↗ · chainup.com
Layer 2 Scaling Solutions: Technical Implementation Guide ↗ · cloudlogic.dev
Read transcript

Cyrus Reed: Iris, hey — okay, I have to tell you, I spent part of yesterday trying to send someone forty dollars and it took, like, three separate apps and I still don't know if it arrived.

Iris Holm: That's the whole episode, actually.

Cyrus Reed: Wait — is it? Because that's what I kept thinking, like, why is moving money still this hard in 2025? And I know Bitcoin exists, I know Lightning Network exists, I know rollups exist — but nothing about that experience felt solved.

Iris Holm: Right. And the reason nothing feels solved is that the problem split. There wasn't one path forward — there were two, and they made fundamentally different bets. That's what we're working out today.

Cyrus Reed: Different bets about what, exactly?

Iris Holm: About what you bring back on-chain. Start with Bitcoin's base layer — seven transactions per second. That's the ceiling. Visa does something like twenty-four thousand. So the pressure was real, and it forced a fork in thinking: do you minimize what touches the blockchain, or do you keep a verifiable on-chain record of everything that happened off it?

Cyrus Reed: Okay but — wait — isn't that kind of the same thing? Like, both Lightning Network and rollups are doing stuff off-chain and settling later, right? That's the same move.

Iris Holm: That's the instinct. It's wrong, though. Payment channels — the mechanism Lightning runs on — open once, close once, and in between you never touch the chain again. Two transactions total, per channel lifetime. Rollups post continuously. Every batch, every proof, every time.

Cyrus Reed: So one is like... you pay the toll at the start and at the end, and the other is paying a toll every mile.

Iris Holm: Close enough to hold for now. The question is what each of those cost structures actually does to the people using it — and that answer depends entirely on who you are.

Cyrus Reed: Okay but — that toll analogy is still bugging me, because I don't think I actually get what's happening in the middle. Like, between the opening and the closing — what is Lightning actually doing?

Iris Holm: Bar tab.

Cyrus Reed: Wait — say more.

Iris Holm: You walk into a bar, you hand over your card, the bartender opens a tab. Every drink goes on the tab — the bartender keeps a running count privately, you trust it, nobody calls the bank each time. At the end of the night you settle once. That's a payment channel. You and the bartender locked funds on-chain at the start. Every round is just a signed piece of paper saying 'now I owe you this much instead.' None of that middle state ever touches the blockchain.

Cyrus Reed: And that's the Lightning Network — a whole network of those bar tabs, chained together.

Iris Holm: Exactly that. Two transactions total per channel — open, close. Everything else is private.

Cyrus Reed: Wait, no — what's a rollup doing differently? Because if Lightning is that clean, why would anyone want... the other version?

Iris Holm: Because sometimes you want the receipt. Imagine a restaurant — every night they bundle up all their transactions, compress them, and send a summary to a public ledger. Anyone can audit it. That's a rollup. Ethereum is the ledger. The restaurant is doing work off-chain, but it's posting proof of that work continuously.

Cyrus Reed: Huh. And that 'proof' part — that's where optimistic versus ZK splits, right? Because I know those words but I don't — wait, are they actually different proofs or just different timing?

Iris Holm: Different proofs. Optimistic rollups say: assume the receipt is correct, but anyone has a window — could be a week — to file a fraud proof if they spot a problem. ZK rollups generate a cryptographic validity proof, a ZK-SNARK or ZK-STARK, for every batch. The base layer checks the proof, never re-executes the transactions. Faster finality. Massively harder to build.

Cyrus Reed: So optimistic is — okay, I'm trusting you but I'm leaving the complaint window open. And ZK is — I'm handing you a mathematical certificate that's either valid or it isn't.

Iris Holm: That's the distinction. And the cost of that certificate is why ZK proof generation is so computationally brutal. The optimistic window is cheaper to produce — but that withdrawal delay is real. You're locked out during the challenge period.

Cyrus Reed: So the bar tab version — Lightning — you're locked in by how much you put in up front. And the receipt version — rollups — you're locked out waiting for the window to close. Different waits, same friction.

Iris Holm: That symmetry is real — but it breaks down the moment you ask what happens inside the channel. Because the wait isn't the only tax. There's a capital tax that runs the whole time.

Cyrus Reed: Wait — a capital tax how?

Iris Holm: Picture a textile wholesaler in Lagos. Six a.m., she's trying to settle a supply invoice over Lightning. The channel's open, funds are locked — that part's fine. But Lightning is a network, so the payment has to hop through intermediate channels to reach the other party. Every hop needs sufficient balance in the right direction.

Cyrus Reed: And if one of those intermediate channels is dry—

Iris Holm: Payment fails. Silently. One channel in that route ran dry overnight from earlier traffic. She has no visibility into why — because channel balances are kept private. The sender just sees: failed.

Cyrus Reed: Okay but — can't you just... reveal the balances? Like, make them public so routing actually works?

Iris Holm: You can. And then you lose the thing that made the channel attractive. The privacy that conceals balances is the same mechanism that prevents surveillance of your payment history. Revealing balances improves routing success rates — but destroys the privacy. Concealing them preserves the privacy but causes exactly the failure our wholesaler just hit. That tension is not a UX problem. It's information-theoretic.

Cyrus Reed: So it's not that the engineers haven't figured it out yet — the two things are actually in opposition.

Iris Holm: Structurally opposed. And it gets worse — Tochner, Schmid, and Zohar identified that the opacity also creates an attack surface. Malicious actors can open channels specifically to manipulate network topology, divert payments through adversary-controlled nodes. The same darkness that protects privacy is the darkness that lets a route-hijacking attack hide.

Cyrus Reed: Wait — so the privacy feature is simultaneously the security vulnerability?

Iris Holm: Same property, two consequences. And our wholesaler in Lagos — she can't rebalance on the fly. Rebalancing means closing and reopening channels. That's capital tied up, coordination cost, on-chain fees. It's not a one-time setup. It's ongoing. That's the structural tax I'm naming — not the initial lock, the continuous drag.

Cyrus Reed: So the bar tab metaphor actually undersells it — because it implies you just run the tab and settle once, but really you might have to open a new tab mid-evening because the bartender's till ran out in a way you can't even see.

Iris Holm: That's the crack. And frankly — the part that comes later makes this look simple, because what rollups can actually do with composability, and what EIP-4844 changed about the cost side of that equation, reframes the whole tradeoff. But that's a different tax structure entirely.

Cyrus Reed: And that's where rollups come in — because the thing you can do on a rollup that Lightning just... can't. Like, structurally can't. Is that where composability enters?

Iris Holm: That's the wall. Payment channels cannot execute arbitrary smart contracts. Not a maturity gap — an architectural one.

Cyrus Reed: Wait — why not? Like, what's actually stopping it?

Iris Holm: A channel is two parties, fixed funds, signed state updates. That's the whole surface. You can't bring a third contract into that without it collapsing into something else entirely.

Cyrus Reed: Picture someone on Optimism, an Ethereum rollup, doing a three-leg DeFi trade. Collateral deposit, token swap, yield claim — all in one transaction. Atomic. That's what rollups unlock, right? Because they're executing arbitrary smart contract code in a shared environment, so those three operations just... compose.

Iris Holm: All three legs either succeed or fail together. Lightning can't touch that.

Cyrus Reed: And that's — that's actually huge. But I was surprised when I went deep on this — EIP-4844. The Dencun upgrade, March 2024. Because blob transactions changed the cost math so dramatically that — wait, no, let me actually say what happened. Rollups used to post data as permanent calldata. Dencun let them post to temporary blobs instead. Materially cheaper. So the rollup cost argument just... partially collapsed.

Iris Holm: Partially. That's the word I'd push on.

Cyrus Reed: How so?

Iris Holm: EIP-4844 proved the footprint is permanent, not transitional. You can compress it. Optimize it. Batch it. You cannot eliminate it. Every rollup is still posting continuously to Ethereum — that's the architecture, not an engineering debt waiting to be paid off.

Cyrus Reed: So the blob thing made rollups cheaper but also sort of confirmed they'll always have this on-chain tail. And — wait, there's a trust surface hiding in there too, right? Because users aren't just trusting Ethereum.

Iris Holm: Right. You're trusting the proof system and you're trusting the sequencer. That's not the base chain. That's two additional layers of assumed correctness.

Cyrus Reed: Huh. So Lightning and rollups both have these trust overhangs — they're just... hidden in different places. And then — okay, Ark. Because someone in 2026 looked at Lightning's setup friction and said, what if we batch the off-chain stuff differently? Pim Keer, Matteo Maffei, co-authors — the paper proposes reducing the on-chain coordination steps through off-chain transaction batching. But it has zero citations as of publication. Zero.

Iris Holm: Which means we don't know if it shuffles the friction or removes it. Same question applies to Fiber Network — Lightning's model ported to CKB, multi-asset support, interoperability with Bitcoin Lightning. Extends the architecture. Inherits the liquidity constraints.

Cyrus Reed: Neither one actually escapes the underlying tradeoff.

Iris Holm: And here's the symmetry that surprised me — optimistic rollups have a fraud-proof challenge window. Could be a week. You cannot withdraw during it. Lightning locks your capital in a channel for its entire lifetime. Both force you to wait. They just bury the wait in completely different places.

Cyrus Reed: So no matter which path you took — channel or rollup — someone designed a waiting room into the system, and just... didn't label the door.

Iris Holm: And neither door is wrong. That's the part I keep wanting to say out loud. Channels are structurally suited for high-frequency, bilateral, private payments — the on-chain footprint is two transactions, ever. Rollups are structurally suited for composable DeFi precisely because they run arbitrary smart contract code in a shared environment. Neither can substitute for the other. Rollups publishing continuously to Ethereum undermines the privacy channels were built on. Channels hit the no-contract wall the moment you need that three-leg atomic trade.

Cyrus Reed: So the question was never which one wins. It was — wait, actually it's simpler than I thought — which cost do you want to pay? A capital tax upfront, locked liquidity sitting idle, or a data tax that runs forever because rollups never stop posting.

Iris Holm: And which cost you prefer depends entirely on what you're building. A merchant doing a hundred bilateral settlements a day — the channel math looks good. A DeFi protocol needing composability and auditability — the rollup footprint is just the price of entry. The tradeoffs are load-bearing. They come from architectural choices at the foundation, not from anything that's going to get engineered away.

Cyrus Reed: The thing that actually clicked for me — ideally a user never has to know which one they're on. Like, the app just makes the right call. You shouldn't have to think 'channel or rollup,' any more than you think 'TCP or UDP' when you send a message.

Iris Holm: That's probably where this lands. The seam should be invisible. Whether it ever gets there — that's a different conversation. But the tradeoffs don't disappear just because the interface hides them. Frankly, that's enough for now.

Why Lightning and Rollups solve scaling differently — and which tradeoff wins depends on the use case · Onpode