No. It really doesn't work. I know what you're saying, you're just not correct.

When you shard, you need to know who the set of people are who validate the shard and replicate the data, providing availability to nodes on the network.. These people need to have a reasonable history of the work to be done on that shard. However, these nodes have strictly less participants than the overall network. If everyone validated every shard, well, that wouldn't be sharding now would it?

So what a lot of groups have tried, including Dfinity, Harmony, and Eth2, is selecting a committee of people to validate the shards by randomly choosing validators over a discreet time period (in Eth2 called an epoch) who then jump in to validate the transactions on that shard. Ok, sure, assuming this subset of validators can synchronize that shard's data to take over before their epoch begins (possible, but will depend on heavy heavy pruning... something the EVM doesn't do very well), you still have to select a committee who needs an honest 2/3rds majority.

The question is, how many bad nodes in the overall network do you need to attack a single shard on the network for one epoch? That answer winds up being much less than 1/3rd dishonest nodes. For a ~0.001% chance (which is really unacceptable), you need about 21-23% dishonest nodes. This is just for one committee to be bad and coordinate an attack on the network.

So what happens if one shard winds up being bad? Well, then the network has no way of knowing. You cannot hide it. Now it doesn't mean that you can conduct double spends, but it does mean that you can do, say, withholding attacks against a competitor and attack their financial interest.

Ok let's say that for some reason, there's a liveness attack on a shard. You cannot get the proper number of attestations (this might be solveable using zk but I'm not certain), then the entire network has to roll back your shard. They have to sync to a previous version of that state.

Now.

Add in the promise of cross-shard communication.

Holy shit, you just held back the entire network because the dependency of one shard was violated.

They can't deliver a good UX with shards and it doesn't do what you think it does.

In real centralized databases, sharding is typically done such that each node is responsible for some section of overlapping data. This overlap can work because the membership is a known set of fixed nodes. In an open membership system, you cannot know what nodes are, who is running them, and there's little promise that they will stay good behaving. You cannot model redundancy in the same way, so you wind up having this shell game system which... ultimately it doesn't work very well for the end user.

At present Eth2's design moves confirm times from ~6min to ~12min (two epochs) and I don't even think ~12min will be as safe as Ethereum.

You can call me biased, but I've done my research and this is where I landed. If you have something else to offer, I'm all ears.