Teranode and how to shard Ethereum without splitting the consensus mechanism

Teranode from Craig Wright who it has been known since 2015 was Satoshi is scaling in a way that respects the Nakamoto consensus (that he invented...), by parallelizing things under the singular central authority, in such a way that everything done below the "miner" is internally trusted. This is exactly how scaling has to be done to avoid splitting the consensus and introducing things like "random sampling", and it seems everyone is missing that.

“One of the key concepts in Teranode is sharding; and when I say sharding, I am not talking about the same thing Vitalik talks about when he talks about sharding and splitting the work among many untrustable parties. [Instead,] we are talking about inside the boundaries of Teranode, where everything is trusted,”

The good thing about this, is that you can "shard" below the already existing protocol. You can likely introduce internal sharding mechanisms, that can become sophisticated enough that the "subnodes" (or "shard validators") can publicly talk to one another and exchange "subblocks" (whose Merkle roots are Merkled together into the actual transaction root in the block header signed by the validator or "master validator"). Any "cross-shard" verification can possibly be done internally mostly, as every other "master validator" with their "sub validators" will verify everything.

No "random samples" as Gavin Wood is doing in JAM in Polkadot or delegating validators to separate shards as Vitalik Buterins's approach has been is needed. Everything internal to the "block of authority" can simply trust everything else there.

The "internal" parts, can even be geographically distributed. A sub-validator on one shard on one side of the world, another on another side of the world. There is no bandwidth bottlenecks.

It might be possible to simply shard Ethereum internally, but in a "public" way where internal parts communicate, but once they have signed off on a block it all appears very similar to how it would appear in the single-threaded version. At least for a simple account-based payment system it seems doing so would be easy. For one with state, even there, contract addresses will cluster in patricia merkle trie and maybe changes on one subnode are relatively easily sent to the "master node" that can keep track of the state trie and sign the block.

I wrote a bit about this idea on my substack, see How to scale Nakamoto consensus and the social centralization paradigm.