I'd say the majority of the modern non-fork networks don't use proof of work and sha256. I'm on a team building one at the moment and we're using sha3.sum512 and no proof of work for production. Some "blockchains" aren't even blockchains of sequential blocks, they are forest DAGs of just transactions.

I think the author's heart is in the right place and I'm thankful that it's being discussed on HN, as blockchain discussions can be a bit hit or miss here.

"The" blockchain is still "a" blockchain. There are many possible blockchain instantiations and Bitcoin is one of them.

Yes, at least if you want to verify the whole chain.

It depends on the implementation. The naive solution is to have every client hold the full chain.

The lightweight solutions come in two flavors, the easy "good enough" solution and the much harder ideal/zero trust solution.

The easy solution (light clients) to avoiding carrying the full chain is to simply rely on some set of known/trusted "beacon" servers that you are willing to trust to relay you the chain state and send you what information you need.

The hard solution is called a "super light" client. One of the famous super light client implementations is called flyclient[1]. It relies on some tricks with proof of work to only store log2(n) blocks out of the n blocks in the whole chain. It gives you enough security to be able to verify that your chain is valid and constructed from the origin block as well as allowing it to use the longest chain rule to decide what chain is the current "official" chain for the network just like you would with a full chain history.

There's another approach called NiPiPoWs [2] (non-interactive proofs of proofs-of-work) which is conceptually similar but is a bit more generally useful (outside of just as a light client system). A few networks adopted it but idk how prevalent its use is nowadays.

Note that flyclient, NiPiPoWs and most super light clients tend to rely on properties of proof of work as well as UTxO accounting models which disqualify their use for most networks. Cardano at the very least seems to have figured their own version out [3][4] and it exists kind of as a conceptual redesign of NiPiPoWs but for stake based systems (and actually came out of NiPiPoW research).

And of course super light clients still require miners to hold the full chain state generally but there's work[5][6] on how to do "light mining" which of course would allow everybody to abandon old chain state and only keep the data they care about.

Note: a lot of the research I linked is inter related as these are the researchers I kept up more closely with last time I was deep in the ecosystem but there's a lot of work on the topic in general coming at these problems from different angles.

--------------------------

1. Flyclient: Super-Light Clients for Cryptocurrencies - https://eprint.iacr.org/2019/226

2. Compact Storage of Superblocks for NIPoPoW Applications - https://eprint.iacr.org/2019/1444

3. Mithril: Stake-based Threshold Multisignatures - https://eprint.iacr.org/2021/916

4. The velvet path to superlight blockchain clients - https://dl.acm.org/doi/abs/10.1145/3479722.3480999

5. Mining in Logarithmic Space - https://dl.acm.org/doi/abs/10.1145/3460120.3484784

6. SNACKs: Leveraging Proofs of Sequential Work for Blockchain Light Clients - https://eprint.iacr.org/2022/240

Gossip protocol.

One can run a pruned node where you only keep block info relating to your associated wallet, but you often keep the whole chain.

The partial collision is easy to verify but hard to generate, consensus is defined as "longest chain is the source of truth". If some p2p node can present you a longer chain you switch your source of truth to that one.