No, a user does not have to broadcast an L1 transaction for any of this to work, although they will make and sign a transaction that looks awfully like one (BIP322 signed messages). That's the beauty of all this - users are completely insulated from L1 transaction fees.
I think the main question by BrotherCreamy can be paraphrased as:
In Lightning, your 'security' is ensured by your ability to 'fall back' / settle channel balances on-chain. If there is any issue, you publish a channel close transaction to the blockchain and get your funds back out.
The question is how this channel closing (and opening) mechanism is eliminated by Settlement Pools.
You're saying that you basically never
need to close your channel / pool?
Nope, it's totally unnecessary. In Settlement Pools, funds are stored in the global M-of-N MuSig (details of which have already been elaborated on in previous posts). Automatic readjustment per block shields it from funds inaccessibility resulting from many settlements going down at once. It would take a global internet shutdown to make the funds inaccessible like that (but then again, L1 would not be able to function either).
There are actually no such thing as channels in my scheme. "Channels" in LN are like a bidirectional telephone line between two people (but only two people). Since the channel is the atom upon which funds rest, it needs to have liquidity, But in Settlement Pools, the settlement does
not have funds. And also, it can have unlimited people subscribed to the settlement at once. It is the network of settlements which collectively have shared access to the global funds address (which is the M-of-N MuSig I keep talking about).
The whole point of having settlement nodes is to decentralize the spending power for the global funds address.
Channels are limited in that they can only deal with two people at once. Funds from multiple channels cannot be "combined" into a single on-gain transaction. This creates a lot of overhead where L1 mainnet is spammed with a bunch of LN closing transactions - though at a slower rate than if you were directly using L1 - so after a while the network will get congested even if it only processed LN transactions.
If Settlement Pools were using ordinary multisig transactions, it would also be susceptible to this problem. But thanks to MuSig[2], it is virtually non-existent - and for this we have Greg Maxwell and co. to thank for their original design proposal. As long as ordinary users are not continuously bouncing their funds between Settlement Pools and L1, the transaction throughout on L1 should handle it all.
