Could a Multi-Chain Bitcoin Help the issue of Scaling? This question falls under the heading of &quot;shower thoughts&quot; that are Generally discouraged in the bitcoin-dev list.
I hope this is the right forum.
I have been running my full node for a few weeks now and have been watching the number of transactions in the memory pool hover around 90K. I'm thinking this is only going to grow and yet we seem to have peaked at an average of 2.5k transactions per block.
I have read of various proposals (BIPs) to fix this but have not seen anyone suggest breaking up the chain into multiple chains.
Currently we have ONE BIG CHAIN that everyone mines...and all transactions go into it...all wallets addresses are contained...
But what if we take half of all addresses (say last digit odd or even) and create TWO Bitcoin chains...
Each chain would start out with:

Half the difficulty setting.
Half the mining reward.
And a special wallet address on each chain that contains all the bitcoins in the other chain. This wallet would not be able to have spends as normal. It would only be able to spend based on the workings on special rules.

Miners would split their mining across both chains. Difficulty would adjust independently as normal. Rewards would continue to halve as expected...however more transactions processed would mean more fee income per block. (Should take 2.5k peak transactions per block to 3.75k per pair of blocks to both chains)
Transactions will go to the chain for the source wallet address (odd or even)
Any transaction that is odd to odd will stay on that chain...This is the savings in mempool and number of transactions as it won't effect the other chain.
Any transactions from odd to even will generate a transaction to the Special Wallet on Odd chain and add a new transaction to Even chain from special wallet to final wallet. And vice versa on the other chain.
The trick here would be having rules for the special wallet so only transactions can be spent from it using the other chains confirmed transaction as Proof. Embedded in that transaction is the spend to address that generates the final transaction on the other chain.  Cross Chain transactions would be a bit slower as they would require a confirmation from 1st chain before adding a transaction to the mempool on second chain... And then the issue of if the first transaction on first chain got orphaned...how would you cancel transaction on second chain...but this is a far as I've gone...
If this works...you could split this up to 3 chains, four chains...etc...with rapidly diminishing returns.
Has anyone heard of this before? Thoughts? Comments?
Thank you for reading!
Ryan
No, I don't think that sharding is as simple or beneficial as portrayed here. Here are a few thoughts:

Splitting by addresses doesn't seem plausible. Most transactions have either multiple inputs or multiple recipients. It's not clear how transactions would be handled that attempt to spend funds from both chains or pay to both chains. If they need to be present on each chain, I don't think we'd get a significant traffic reduction on either chain. If they do get included on both sides, how do we ensure that they don't get confirmed on only one side? If they can only be included on one side, how do we coordinate that?
ETH has been working on Sharding since 2016(?), and as far as I can tell, it requires layers of mitigations and complexity, and comes with all sorts of trade-offs. ETH requires global state for each transaction's execution. By introducing sharding, ETH gets multithreaded validation. Bitcoin's transactions are inherently stateless, and its scalability concerns are related to total resource usage. Two shards of 0.5 MB blocks are no better than one chain with 1 MB blocks for that. Two shards with 0.5 MB blocks that have a storage footprint of 0.75 MB and coordination overhead sound like a step back.
It sounds like a complete consensus overhaul. It's unlikely that people would be comfortable to support such a proposal.

That said, we already have some sidechains and second layer solutions that we can offload transaction traffic to with far less overhead or critical changes.