Well, you don't do LN transactions on a blockchain at all, that's where the speed improvements come from. It's all a lot more ad hoc than that. If I send you $5 via the LN, then the only communication that needs to happen is between us. We do _not_ announce it to the world like you do for a blockchain, there's no one centralised ledger of events. Eventually we need to "settle" our payment channel, because the way this works is that in order to send you $5, I need to commit that $5 to a payment channel first (which requires a bitcoin transaction to lock that money in place), send it to you via the channel, and then we can settle the payment channel (which requires another transaction to unlock the money, except to you instead of me)

This is extremely inefficient for one transaction, though. You'd really need to commit a lot more money to your payment channel so you can use it for many things. If you use it for more than two things, you're gaining efficiency, but rememebr that you can't add money to it or take money out without going onto a blockchain.

This unfortunately still leaves us with the cruical flaw of blockchains, in that they're a decentralised and consistent ledger and that's actually really expensive to maintain. It's why there's so much push-back against making bitcoin's blocks bigger, 'cos the bigger your blocks are the harder it gets to move everything around fast enough to keep things running. It might seem trivial to move 1MB every ten minutes, but remember that that's 1MB every ten minutes to every node on the network, sometimes via connections which aren't very fast. Most notably, the great firewall of china is actually not very fast at all, and so blocks moving into and out of china have to do so relatively slowly. We triple the block size and maybe we can't keep up any more, and if the network can't talk to itself fast enough to move blocks around every ten minutes we have a network partition that won't fix itself and a big problem.

And that's fundamental, right? You can strip out PoW, you can tune all the values you like, it's just a question of bandwidth. 10MB blocks every ten minutes, 1MB blocks every minute, 100kb blocks every few seconds, it doesn't matter. The bandwidth to move that around a distributed global network isn't there. We can move all the LN opens/settlements to a different blockchain, but all we'll do is make it so that we have scaling problems on a different blockchain.

To be perfectly honest, I can't see a way for it all to work smoothly. There's unsolved, Hard-with-a-capital-H distributed computing problems which need solving to make this work, and there hasn't been any progress made towards solving them. Bitcoin and friends appear to work because they balance in a kind of "habitable zone" between throughput and usage, where eschewing Consistency and Partition Tolerance from the CAP theorem doesn't seem too bad, because even though we've dropped Consistency the fact that we don't really get long network partitions means that your transactions aren't going to get undone very often (but it absolutely can happen!), and even though we've dropped Partitian Tolerance that isn't that bad because we don't really get long network partitions and we have a partitian resolution operator that only drops transactions sometimes.

But if blocks can't get around the network fast enough then suddenly we do get major network partitions, and that means our mitigation for lack of consistency falls apart, and so we don't have a working partition resolution operator. We're left with our choice to pick only "A" from CAP, and have a highly available network that doesn't reliably commit transactions and very often splits into multiple partitions. Argh!

Multiple blockchains could mitigate this issue, but they can't really talk to each other very well, not without incurring further losses of efficiency. In that scenario we'd need four transactions to send our $5 - one to open the channel, one to close it, and two to jump blockchains. Ack!

These are just really hard problems and hopefully they can be solved, but right now there are no even proposed solutions which can fix this.