OP, thanks. I'll stick to the proven Bitcoin POW/blockchain, and the federated Liquid Network sidechain combination. But you should develop it, and make an altcoin out of your idea, good luck.
I do not get why I come across so many people like you on this forum, all talk about staying true to satoshis decentralization and fully supportive of decentralization and then you come out and say that you would rather stick with a federated sidechain, so you are okay with a member of 30 or so organizations being able to hold your coin hostage if needed? Liquid's federation makes the security provided by Bitcoin's POW useless. When will I stop coming across such trash comments.
You provide nothing useful in your comment and then come out to say you will stick with federation.
I think , adding votings to a unconfirmed transaction is a solution .
How it works --
1. Someone broadcast a transaction (maybe with tag like dynamic transaction) to p2p network .
2. Each node receiving the transaction see if its a valid transaction (say by applying AcceptToMempol/AcceptableInput),
2a. If successful (Transaction is fully valid ) , give upvote(with some sort of signature )
2b. If failed (Transaction is not good) , do nothing or give downvote
3. Now, Network count the votes,
3a. If upvotes - downvotes >= certain amount of votes (say 100, i.e. upvotes - downvotes >= 100);
then assume transaction is valid and can be spent, (with proof that it has enough upvotes )
3b. If downvotes > upvotes ,
then transaction is not valid and should not be submitted to miners.
4. A transaction having enough upvotes submitted to miners (that in 3a)
How it works --
1. Someone broadcast a transaction (maybe with tag like dynamic transaction) to p2p network .
2. Each node receiving the transaction see if its a valid transaction (say by applying AcceptToMempol/AcceptableInput),
2a. If successful (Transaction is fully valid ) , give upvote(with some sort of signature )
2b. If failed (Transaction is not good) , do nothing or give downvote
3. Now, Network count the votes,
3a. If upvotes - downvotes >= certain amount of votes (say 100, i.e. upvotes - downvotes >= 100);
then assume transaction is valid and can be spent, (with proof that it has enough upvotes )
3b. If downvotes > upvotes ,
then transaction is not valid and should not be submitted to miners.
4. A transaction having enough upvotes submitted to miners (that in 3a)
This does nothing to increase scalability, time is still going to be taken to communicate with all nodes who vote with each other, would not work alone.