Trustless scaling within a node through "coalition" method

So, Bitcoin has the potential to scale to a practically infinite block size by managing things internally with delegation. Picture a group of 1024 folks handling 1024 times bigger blocks, although this needs some ordered Merkle tree setup for parallel coordination and filtering transactions in the mempool by their hash range. But the whole trust thing kinda hits a wall based on Dunbar's number, so realistically, teams would probably be more around 16 to 32 people, which would only get you 16 to 32 times bigger blocks. But wait! You can still have trustless coordination while scaling within the node. A lot of blockchain projects throw around ideas like "split the blockchain into 16 shards", but it’s totally doable for nodes to scale internally however they want with similar trustless methods. You could do what’s called "stateless validation", where block validation and production get randomly delegated within the team, so nobody knows which "shard" they’ll be working on at a given block. Each member has their own shard to keep their piece of the blocks and UTXO database. Throw in a random audit round like what Polkadot has done. Then everyone in the team can mine together on the block, which shows their commitment to a specific node-as-a-team (and this behaves somewhat like a "coalition" in the consensus mechanism, especially when you think about proof-of-stake). Plus, the node can also tap into P2pool or something similar to join a bigger mining pool.

No the beauty of it is that you can propagate transactions in blocks and mempool by transaction hash ranges, so that rather than being node-to-node it becomes sub-node to sub-node. So if you take 1 MB block size, and then instead do 1024 sub-nodes with 1 MB "sub-blocks", you get 1 GB blocks but each sub-node manages roughly the same bandwidth and computation and storage as the 1 MB block single-node (on a simple trust-based version they manage upwards twice the sub-block size to include the UTXO requests and such between one another, with the trustless approach it is probably still roughly same). This is why it scales to infinite block size. Note, it requires an ordered Merkle tree, so that sub-nodes can do parts of the block by themselves and know what part (and then only assemble the Merkle root together).

Exactly. And if pooling of validation can be done "underneath" Nakamoto consensus and internal to the validator, no reason to centrally agree on how it has to be done (i.e., the approach Vitalik Buterin and many have). Anyone who has to pool to compete with the larger block size is incentivized to do so, and to figure out how to do so, or they do not get paid (as they cannot validate, only the beefy nodes can manage such large blocks on their own).

In the sharding debate, this model can be positioned as intra-validator sharding subordinating inter-validator sharding. It combines the best of both worlds. Thesis, anti-thesis, synthesis. I made an illustration to show it. Thesis: Inter-validator sharding Anti-thesis: Intra-validator sharding Synthesis: Intra-validator sharding subordinates inter-validator sharding With the synthesis, a node can do as it wants, shard or not shard, use trust or trust-minimization, thus it is dynamic to need relative to available hardware just as is the rationale for intra-validator sharding, but it supports teaming up as is the rationale for inter-validator sharding. It is the best of both worlds, exactly. Also more complex, but self-organizing (nodes are incentivized to solve the needs they themselves have for their level of available hardware and bandwidth, there is here no one-size-fits-all solution to sharding).

IMO and nothing more this looks like an answer in search of a question. Off the shelf hardware that is YEARS OLD can more then handle much larger blocks then we are doing now. I have a customer who is running 3 7th gen PCs each with 2 VMs on it All 6 VMs are the same and are running full nodes of BTC - BCH - LTC - ETH -[I forgot the 5th coin  ] Along with whatever software it needs to talk to the ATM. And they are not even stressing. Same with the bandwidth. Eliminating the IBD even someone on 56k dial up internet could keep up with 16 meg blocks. Yeah you don't want to run a node on dial up but the point remains the same. By the time we get and need much large block validation old hardware will be that much more powerful. As I started with,IMO not saying it's not a good idea, just that it's not really needed at the moment. -Dave

Dave the position you describe is the "intra-node sharding" side. This is one of the two "sides" in the scaling debate, and the other is "inter-node sharding". In the "intra-node sharding" side one argument is typically that advances in hardware means intra-node sharding will always be sufficient. The "inter-node sharding" side rejects that claim. Two sides, that both claim the other is wrong, two sides that cannot be reconciled. I simply point out that both sides can be combined into a unified model. Then, reality can show who was right and who was wrong (most likely, both sides were right on some things and wrong on some things).