My apologizes for not responding in this month, I've been busy in rl and wanted to have the time to answer adequately.
So basing on what emerged by this topic, it seems like there are a several ideas with similarities to my proposal, but the thing that I think differ is the fact that this L2 should work as an aggregator of transactions with the capabilities of transmiting both send/receive addresses and amounts to the Bitcoin Blockchain.
What I actually propose is to create a protocol that aggregate groups (boxes) of transaction instances, made on the layer2, and finalize them by transmitting to the Bitcoin Blockchain. This would reasult in a "many to many" transaction in the main Blockchain, where the many senders and receiver are indicated by the informations stored in the boxes. Thus, the layer2 should be able to deploy transactions on the main blockchain, after gathering all the transaction instances initialized in the l2.
This would result in a much higher number of transaction per second that the network could handle and also a decrease in fees, since every transaction fee would be divided by the many senders aggregated in the boxes by the L2.
One of the main doubts that I have is that, even if there's the option of onetomany transactions and that a single l1 transaction can have multiple inputs, I'm not sure it would be possible to create a transacion with multiple inputs by different public(private) keys.
Hope you'll still be interested in discussing this proposal.
You actually can make transactions with different inputs like that, but the transaction instances will quickly fill up blocks, leaving less room for other transactions - a direct consequence of jacking up the TPS.
For a Layer 2 system to be effective, it needs to be able to consider L2 transactions as
immediately confirmed, without waiting for L1 to mine it in a block. In case it never makes it, then that is considered a "chargeback" and appropriate penalties can be taken by service providers, just like in a regular bank.
Otherwise, it is just a proxy for creating L1 transactions.
Also, to support many tps (I'm particularly gunning for 1 million transactions per second!), the L2 transaction data must either be ephemeral, as in, the invoice is reduced to a transaction ID once it is mined and the L2 transactions in it deleted, OR your wallet that uses whatever L2 implementation actually
becomes its own bank and keeps only its own transaction records and no one else's.
I think the second option is more viable. In the case of multiple personal devices, you can sync your own transaction data across your local LAN or WiFi network.