A proposal for a genuinely distributed blockchain and pruning The following idea is so simple that I cannot believe that it is really new. It must have been presented and discussed at length (and rejected) previously, but I submit it nevertheless, for lack of having found any mention of such discussions.

The basic idea is simple : when a (full) node successfully adds a block to its copy of the blockchain, it broadcasts an inv message giving its address and the identity of the block.

Every node is thus able to maintain for every block a list of nodes having that same block in their blockchain. That inventory will normally be separate from the local blockchain.

Now every node can decide, based on local considerations, whether to include a block in its local blockchain or to only include a small placeholder and call upon other nodes if and when the full contents of that block are required. That would be a base for a genuinely “distributed” blockchain.

In practice, all nodes would probably want to initially include all full blocks, since at that time they would not have identified enough nodes carrying the same block. A capability to replace an existing block with a reference to other nodes would therefore be required. To that effect, block headers should include a reference to the (local) list of alternate source nodes for that block.

A node could then simply erase the payload of a node in its copy of the blockchain, retaining only the header unchanged, including the hash of the full block and of the previous block to retain continuity of the chain. Of course that should be broadcast so that the ofher nodes update their local table of alternate sources.

When a scan of the blockchain hits a block with an empty payload, the node could return a "block unavailable" answer (for instance if multiple nodes are being queried), or the local list of alternate sources for that block could be used to retrieve a copy (or many copies for verification purposes), which could be checked using the hash retained in the abbreviated header.

Some mechanism for ensuring that each block exists in full version on a sufficient number of nodes would be required. 

What is wrong with that proposal ?
One thing you're missing is that nodes don't actually need access to blocks.

The only time a "scan of the blockchain" occurs is to give historical blocks to another node that is syncing, or to find historical transactions a wallet missed. Solutions for those case are not hard. Sequential bulk storage and bandwidth are cheap and it's not something every node on the internet needs to provide to everyone. You can find movies on the internet for free that take not much less space than the block chain. 

Modern full nodes can even run without keeping blocks on disk at all (see the -prune option in Bitcoin Core). In this mode, all blocks are still downloaded and verified one by one, but not kept on disk after verification. The only thing that is kept is the UTXO set - the database of the current state of the ledger, rather than its entire history. This is sufficient for validating future transactions and blocks, participating fully in the P2P network, and provide wallet functionality.

So can't we use your idea for the UTXO set instead then? Maybe, but it's pretty pointless. The reason you run a full node in the first place is to be able to verify that nobody is violating any of the rules. If you're willing to not do that completely anymore and instead start relying on trusting some of your peers, why bother? Bitcoin provides a lightweight mode where you don't need access to either the blockchain or the UTXO set at all.