Quote
In order to use L2, you need L1; does the same apply for L3 & L4?
I think so. In order to use L3, you need transaction batching feature, so some kind of Pedersen Commitments or things like that are needed. I guess in L3 you cannot join any transaction with any script type, just that transaction types when it will be enabled, for example only those with some kind of future Segwit version address or those with some kind of future-tapscript (because taproot is self-upgradeable).Quote
Would L3 need L2 to operate?
Yes, because in other case it won't be L3, but just another L2.Quote
To me, it seems that, by the way you wrote it, L3 is a L2 update (?).
I guess that garlonicon's way of thinking is "what needs to be outside". In Segwit, signatures are outside. In taproot, signatures are batched. In L2, transactions are outside. In L3, transactions will be batched. In L4, everything will be reduced to single commitment. So I guess in L5, commitments would be batched, for example instead of using one commitment per block, it could be one commitment per 2016 blocks.If you want to create L3, you have to "push something outside" and because channel creation/destruction transactions are the only things that are present on-chain, then something related to that should be "outside". And batching is "pushing things outside", because in that case you can open some channel, you broadcast channel opening transaction to the "L2 mempool". Then, you do your L3 transactions, but "L2 mempool" is very congested. Finally, you close your L2 channel, but your channel opening transaction is not yet settled on L1. So, it can be reduced by using Pedersen Commitments or some other kind of transaction batching. Of course, to avoid double-spending, some kind of "honest batching proof" will be needed, because if Alice opened a channel with Bob, and Bob opened a channel with Charlie, it should be possible to close all channels and create a payment from Charlie to Alice without worrying if it should be from Charlie to Daniel.
Going further, if you have batched transactions on L3 and it is still not enough, then you have to "push something else outside". And the only thing I can think of is pushing transactions outside. For that, you collect all L3 transactions and create a 256-bit commitment. Going even further from L4 to L5, you have to "push something else outside". You have single 256-bit number per block. How to reduce that? Make one commitment per 2016 blocks. I still wonder how to create L6 by using that kind of logic, but it seems that L5 will be sufficient for a long time.
